Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

Subscribe to fpga-cpu



fpga-cpu by Keywords

Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A


Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | FPGA-CPU | Latching LUT ram outputs

This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).

Latching LUT ram outputs - Author Unknown - Nov 3 4:44:00 2001

I know it's been mentioned before, but I couldn't find the post, so...
Is it possible to latch (not reg.) the output of LUT ram in the
SpartanII on the falling edge of the clock, while write is on the
rising edge (in the same slice) ?

Thanks
Rob





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )


RE: Latching LUT ram outputs - Jan Gray - Nov 3 11:10:00 2001

> Is it possible to latch (not reg.) the output of
> LUT ram in the
> SpartanII on the falling edge of the clock, while write is on the
> rising edge (in the same slice) ?

To my knowledge, nope.

See
http://www.fpga-faq.com/FAQ_Pages/0023_Clocking_Rams_and_Flip_Flops.htm

Follow the thread using the T>> links.

Jan Gray
Gray Research LLC




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: Latching LUT ram outputs - Jan Gray - Nov 3 11:53:00 2001

Although I have not been doing this lately (building a register file
with one read and one write access each cycle, using single port LUT
RAM), nevertheless I suspect the best way to implement this in
Virtex-derived architectures is to run the register file at twice the
frequency of the rest of the design, either using two clocks (one
doubled), or by using half-duty-cycled clock-enables everywhere else.
Either way, you will then have to do somewhat more work specifiying
TIMESPECs -- a simple PERIOD constraint probably won't do.

Similarly, if you aren't in a hurry, you can also build a 2R-1W/cycle
register file using a single bank of single port LUT RAM, by running the
register file at *three* times the pipeline clock rate. Here
floorplanning and/or replicating the FFs that drive LUT RAM control
signals (A, WE) will be critical.

Jan Gray
Gray Research LLC




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: Latching LUT ram outputs - Ed Corter - Nov 3 12:44:00 2001

Date: Sat, 3 Nov 2001 08:53:15 -0800
Reply-to:
Subject: RE: [fpga-cpu] Latching LUT ram outputs

yes a 2x clock for this portion of the design will
work with the Virtex devices.

I have a custom UART design that is zipped. I used
this approach on the receiver FIFO. If anyoune wanted
this Verilog I would be happy to dig it out.

Ed Corter

__________________________________________________
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Latching LUT ram outputs - Author Unknown - Nov 5 3:29:00 2001

> yes a 2x clock for this portion of the design will
> work with the Virtex devices.
>
The problem with using a 2x clock is that I then have to pass a clock
enable everywhere to the slower parts of the design and believe it or
not the added logic for the clock enable slows the design down, not
to mention using up additional routing and logic cells. Also using a
2x clock increases the amount of power required (P=c^2 x f ?) Have I
got that right ? It seems silly to me to use a 2x clock for the whole
design when only one thing (the register file) may depend on it.
I've managed to eliminate the need for a 2x clock in a couple of
other spots by using a cheesy clock doubler where the timing isn't
critical. But I think the timing is too critical for the register
file. Anyway I think I can live with the extra delay needed to route
the ram outputs to another slice to use the opposite edge of the
clock. But does this use up the other slice ? or can the luts in the
other slice still be used for other logic ?

The other possibility that's occurred to me is to use a clock dll.
But can I use both the original frequency (1x) and doubled frequency
(2x) outputs of the dll ? I've got the impression that you have to
treat the dll outputs as if they were a different clock domains. It
sure would be nice if both clocks were exactly in sync and could be
treated as the same domain.

What I'm actually implementing is a r3w1 register file by using dual
port ram at ddr. Same idea as using the single port ram at ddr, but
more ports. Rob





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: Latching LUT ram outputs - Ed Corter - Nov 5 9:32:00 2001


--- wrote:
> > yes a 2x clock for this portion of the design will
> > work with the Virtex devices. > The problem with using a 2x clock is that I then
> have to pass a clock enable everywhere to the slower
parts of the design
and believe it or not the added logic for the clock
enable slows the
design down, not to mention using up additional
routing and logic cells. Also using a

clock enable everywhere...
I had to do this with almost thing in my design
probobly because the GCLK rate was 93.33 mHZ and as
far resorce usage.. I was targeting the
1000E . So I had a field of gates to play with.
To keep Place and route times reasonable I made use of
the many constraints that
are available for application. I created timing groups
and applpied min delay
requiremets that were optimal for the specific group
and applied that delay constraint to
the group. > 2x clock increases the amount of power required
> (P=c^2 x f ?) Have I
> got that right ? It seems silly to me to use a 2x
> clock for the whole
> design when only one thing (the register file) may
> depend on it.

This is true if the 2x clock is driviving the entire
design; however,
In my design I only used the 2x clock for 2 State
Machines and the FIFO Core: the rest 1x.

> I've managed to eliminate the need for a 2x clock in
> a couple of
> other spots by using a cheesy clock doubler where
> the timing isn't
> critical. But I think the timing is too critical for
> the register

If in the Virtex, I believe that ther is 8 DLL's in
the chip.
I have spent a couple weeks when I first started usin
the Virtes E's just for charicterizing
the DLL's performance for the following functions:
PCB trace delay deskew, 2x, 4x, & lock signal
behavior. The 2x is very easy to implement. > But does this use up the other slice ? or can
> the luts in the
> other slice still be used for other logic ?

This I can't answer off of the top of my head. > The other possibility that's occurred to me is to
> use a clock dll.

yes yes !!

> But can I use both the original frequency (1x) and
> doubled frequency
> (2x) outputs of the dll ? I often have used both
and have that UART design that Includes
a block called "clocks_n_reset" this shows The DLL's
are instantiated here.

I've got the impression
> that you have to
> treat the dll outputs as if they were a different
> clock domains. It sure would be nice if both clocks
were exactly in
> sync and could be treated as the same domain.

***** Importent ******

This is where the beauty of the constraints comes in !

with two clocks out of the dll they have two different
names.
Of course at the dll's outputs they are perfectly
synchronized; but, if this 2x clock signal
name is never treated special ( constraint wise ) it
will incurr lots of delays as P & R brings
it to where it is needed in the design.

for the 2x portion of the design you can constrain the
the bits beig clocked as a group to arrive
x nano seconds before or after x edge of the name of
the 2x clk signal !
__________________________________________________





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: Latching LUT ram outputs - David Spencer - Nov 5 11:30:00 2001

just a thought (from a beginner so ignore it if it's completely stupid)

it occurs to me that if you can trigger on 0->1 but not on 1->0, why not
define clock-bar and trigger on it's 0->1 which is of course the
original clock's 1->0?

Dave.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: Re: Latching LUT ram outputs - Jan Gray - Nov 5 11:50:00 2001

The problem is, for speed, you want to locate the RAM16X1S LUT RAM in
the *same slice* as the latch. So, if you feed clock_bar (or better,
take advantage of the built-in clock inversion in the slice
interconnect), then you also invert the LUT RAM WCLK (write clock). In
Virtex and derived architectures, it does not seem possible to write
into the RAMs on one edge and reigster (or latch) the RAM outputs on the
other edge, in the same slice.

Jan Gray
Gray Research LLC




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: Latching LUT ram outputs - Ed Corter - Nov 5 11:51:00 2001


--- David Spencer <> wrote:
> just a thought (from a beginner so ignore it if it's
> completely stupid)

nope not completely stupid ! my terinology my not be
acepted largely:; but, I refer to that as
"NOT CLOCKING" the NOT being inversion.

I have also done this in similar situations.

Also if anyone has chipscope, I have found it to be a
great tool for seeing what is going on internally with
signals. I would not be able to give the ChipScope
suite away for free :(
Xilix would get upset... sorry ! __________________________________________________





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: Re: Latching LUT ram outputs - Saurav Bhattacharyya - Nov 5 22:00:00 2001

Talking about chipscope ..
I would like to know if anybody on this group has been able to get the
following combination working for Chipscope:

Xilinx Foundation 3.1i
Xess v1.0 carrying a XCV800
Chipscope
Port - parrallel/JTAG/Xcheqer/ anything will do ...

Saurav.

NTU-Singapore > -----Original Message-----
> From: Ed Corter [SMTP:]
> Sent: Tuesday, November 06, 2001 12:52 AM
> To:
> Subject: Re: [fpga-cpu] Re: Latching LUT ram outputs > --- David Spencer <> wrote:
> > just a thought (from a beginner so ignore it if it's
> > completely stupid)
>
> nope not completely stupid ! my terinology my not be
> acepted largely:; but, I refer to that as
> "NOT CLOCKING" the NOT being inversion.
>
> I have also done this in similar situations.
>
> Also if anyone has chipscope, I have found it to be a
> great tool for seeing what is going on internally with
> signals. I would not be able to give the ChipScope
> suite away for free :(
> Xilix would get upset... sorry ! > __________________________________________________
>
> To Post a message, send it to:
> To Unsubscribe, send a blank message to:
>
>




______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: a verilog shifter \ rotater - Ed Corter - Nov 11 18:07:00 2001

The design is a rotate \ shift module. it's interfaced
via two address.
a0 is the operand write(the Number to operate on)
a1 sets the mode and direction with Bits[5:4]
I.E. shift or rotate & left or right.
Bits[3:0] set the count for the N time that the
operation is performed.

the resul t is out on a seperate bus.
I am almost done with the design: I am simulating and
it looks good so far.

Any suggestion or input ???
When complete, I will post a web address where a final
description of the module and all files including the
sim bench.. Also resoure usage report and timing. __________________________________________________


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: a verilog shifter \ rotater - Author Unknown - Nov 16 1:11:00 2001

--- In fpga-cpu@y..., Ed Corter <artiedc@y...> wrote:
> The design is a rotate \ shift module. it's interfaced
> via two address.
> a0 is the operand write(the Number to operate on)
> a1 sets the mode and direction with Bits[5:4]
> I.E. shift or rotate & left or right.
> Bits[3:0] set the count for the N time that the
> operation is performed.
>
I can't tell much from your post; but, the one comment I have would
be to separate the mode and direction bits from the count. These are
basically control signals. I think the mode and direction should be
derived from the cpu's instruction register, and not encoded as part
of an operand. Using an operand to determine what instruction to
execute is a form of self modifying code, some people would consider
this a no-no :) It might be extremely difficult to come up with a
compiler capable of using operand values to determine how the shift
is done. Of course, if this shift module is for something else, I
could be way off base...

Rob http://www.birdcomputer.ca/





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: a verilog shifter \ rotater - Ed Corter - Nov 16 8:31:00 2001


> I can't tell much from your post; but, the one
> comment I have would ...... execute is a form of
self modifying code, some people would consider
this a no-no :)

Hi Rob, I'ts not exactly part of the operand; but, a
write operation to the module is required to set it
up. To make the module more friendly for integration
into a CPU structure...should I bring the Count bit's
and mode \ direction bits out as a bus that is to be
driven by a uP control register ??

I would be more than happy to make a couple of change
if it would make this module more usefule for
peoples...

Thank's
Ed Corter

__________________________________________________



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )