Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
You don't say what the cycle time needs to be. Assuming you can use multiple
clock cycles to interface the ram.....
__ __ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__|
___ ________________ ________________ ________________ _
A/D ___{}________________{}________________{}________________{}_
________ ___________ __________________________
R/Wn \_____/ \_____/
Cycle WRITE1 WRITE2 READ1
This example uses 3 clocks/cycle, in your case 10 Mhz (100 ns) access. If this
is ok, this is a clean way to do it. If you don't mind using both rising and
falling edges in your design, here is another way that allows for 15 Mhz
access....
__ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |
___ __________ __________ __________ _
A/D ___{}__________{}__________{}__________{}_
_____ _____ _________________
R/Wn \_____/ \_____/
Cycle WRITE1 WRITE2 READ1
Hope this helps.
Louis Zhang wrote:... snip ...
> The problem of the asynchronous SRAM is with its write operation, where
> the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> address (and data) is stable, and deasserted ('1') "shortly" before the
> address (and data) changes. In other words, R/Wn has to be deasserted
> ('1') when address or data change.
>
> The desired waveform looks like this:
>
> CLK= 30MHz
>
> _______ _______ ________ ________
> CLK | | | | | | | |
> ____| |_______| |_______| |______| |_____
>
> R/Wn _______ ______ _______________________________
> | | | |
> |__________| |_________|
>
> Addr -------------------------------------------------------------------
> RA0 | WA0 | WA1 | RA1 | RA2
> | | | |
> -------------------------------------------------------------------
>
--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 13426ez wrote: <some text deleted> > Did the people that created FPGA Express ever used their > own tools ????? It seems they like to click their mouse all > the time, yes, when updating a design that contains errors, > you have to click another design first and then click the > updated design to see the errors. Oh, well, meanwhile you > can always entertain yourself watching their beautiful > 'Internet Explorer copy' flashing lamp to keep yourself from > getting nervous. FPGA Express comes from Synopsis and is bundled by Xilinx. I agree it sucks! Fortunately, the only thing I use it for is my grad course in Verilog. At work we use a "real man's" synthesizer... Exemplar's Leonardo. Just in case Synopsis is listening, here are a few suggestions... 1) TCL scripting. Let the designers make a script that they can use over and over instead of click, click, click, click..... click! 2) How about better reporting? Give us a clue as to how well the tool is optimizing the design. How many levels of logic did the tool make? 3) A way to run everything from NT command line, so that synth and back-end can all be run from batch file w/o user interaction. -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 13427
What factors would determine the *lowest* clock frequency that can drive a given digital circuit? (I can very well understand the existence of a an upper limit.) I think this kind of limit doesn't exist on all digital circuits. Can you come up with a possible scenario that would place a limit on the MINIMUM clock freq reqd? One possible scenario: DRAM circuitry would fail if the r/w clock freq is less than the refresh rate. Thanks in advance, --shail -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13428
Joseph H Allen wrote: > And are they planning on releasing the GHz speed existing 4000-series > FPGA? > No! Instead they are going to release a large, but much slower new > FPGA > with this technology. Oh well. > Wise guy ! Where do you get all this wrong information from? Why the bitching, especially when it's based on wrong assumptions? And who says that Virtex is "much slower" or always large ? Read the data sheet, it's available on the web. Incidentally, I built and demonstrated a 6-digit frequency counter with an input resolution of 420 MHz a year ago, using good old XC4002-09. It can be done, even with worst-case timing analysis. All our devices are getting much faster. Don't worry, be happy. Peter Alfke, Xilinx ApplicationsArticle: 13429
Hi Brian,
Thanks for your response.
Unfortunately, the cycle time needs to be 30MHz as well,
and I cannot use a 60MHz or 90MHz clock to produce the
30MHz clock.
Thanks.
-----------------------
Louis Zhang
lzhang@eecg.toronto.edu
On Wed, 2 Dec 1998, Brian Boorman wrote:
> You don't say what the cycle time needs to be. Assuming you can use multiple
> clock cycles to interface the ram.....
>
> __ __ __ __ __ __ __ __ __ __
> CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__|
>
> ___ ________________ ________________ ________________ _
> A/D ___{}________________{}________________{}________________{}_
>
> ________ ___________ __________________________
> R/Wn \_____/ \_____/
>
> Cycle WRITE1 WRITE2 READ1
>
> This example uses 3 clocks/cycle, in your case 10 Mhz (100 ns) access. If this
> is ok, this is a clean way to do it. If you don't mind using both rising and
> falling edges in your design, here is another way that allows for 15 Mhz
> access....
>
> __ __ __ __ __ __ __
> CLK __| |__| |__| |__| |__| |__| |__| |
>
> ___ __________ __________ __________ _
> A/D ___{}__________{}__________{}__________{}_
>
> _____ _____ _________________
> R/Wn \_____/ \_____/
>
> Cycle WRITE1 WRITE2 READ1
>
> Hope this helps.
>
>
> Louis Zhang wrote:... snip ...
>
> > The problem of the asynchronous SRAM is with its write operation, where
> > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > address (and data) is stable, and deasserted ('1') "shortly" before the
> > address (and data) changes. In other words, R/Wn has to be deasserted
> > ('1') when address or data change.
> >
> > The desired waveform looks like this:
> >
> > CLK= 30MHz
> >
> > _______ _______ ________ ________
> > CLK | | | | | | | |
> > ____| |_______| |_______| |______| |_____
> >
> > R/Wn _______ ______ _______________________________
> > | | | |
> > |__________| |_________|
> >
> > Addr -------------------------------------------------------------------
> > RA0 | WA0 | WA1 | RA1 | RA2
> > | | | |
> > -------------------------------------------------------------------
> >
>
>
>
> --
> Brian C. Boorman
> Harris RF Communications
> Rochester, NY 14610
> XYZ.bboorman@harris.com
> <Remove the XYZ. for valid address>
>
>
>
>
Article: 13430> Also, it has been my case (having to complete > designs for people who left) that how good the tools operate for you is > directly related to how well you design the circuitry you want to fit. Poor > design practices makes for poor routing/timing in the final design. Design practices are not the issue, I believe I'm quite well versed in Xilinx design practices...;-) The problem is a design that routed and made timing using the old tools, now doesn't make timing using the new tools, using the same part. > Last, as buggy as Epic is at times (both the Lucent and Xilinx versions), the > capability to go in and make tweaks during debug/integration is very helpful. Agreed, but NeoCAD didn't invent that. In fact, XACT/XDE was the first tool that was available for Xilinx FPGA design....back 10 years ago. It has been a standard tool since then, and is in all the tool sets. EPIC is a 'copy' of this tool, it is not a new idea. The problem is, EPIC is more difficult to use, and is missing some very useful features that the previous Xilinx tool (XDE) had. AustinArticle: 13431
shailbains007@my-dejanews.com wrote: > What factors would determine the *lowest* clock frequency that can > drive a > given digital circuit? (I can very well understand the existence of a > an > upper limit.) > Circuits using static logic have no lower limit for their clock frequency ( but even at a low frequency, the clock edges must be crisp with short transition times, below 10 nanoseconds). Some logic stores information not in static latches, but on capacitors, where the data will leak away. DRAMs are the most widespread users of this space-saving method. In that case, there is a max time between refreshing clocks. In non-DRAMs, such dynamic logic is rare, so most logic can be clocked at zero frequency. All Xilinx FPGAs and CPLDs are completely static, except for the serial configuration input to the XC3000 devices, where CCLK must not be parked Low. Hope this helps. Peter Alfke, Xilinx ApplicationsArticle: 13432
Louis,
1. Data doesn't (usually) need to be stable *before* the assertion of
/WE,
just needs to be stable (setup time) before *deassertion* of /WE.
Many Async SRAM data sheets are misleading.
2. Use CLK for *CE. Assume CLK is generated off-chip.
3. Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.
4. ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
CLK->Q->pin min prop delay through, which should be greater than
the SRAM's min HOLD time req. for ADDR/DATA/*WE.
5. ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi)
width,
less max prop delay of CLK->Q->pin path through FPGA.
Pick a combination of SRAM speed and FPGA speed that suits timing
constraints 4 and 5. SRAM will need to be faster than 15nS access,
but these are readily available in 1Mb ($3 US, roughly) and 4Mb
sizes.
6. Make sure you "manage" onboard interconnect skews for
CLK/ADDR/DATA/*WE.
7. If you want to read from SRAM, don't assert *WE. *WE is the output
of
a normal on-chip FF, clocked by CLK(^), with same timing as
ADDR/DATA.
_______ _______ _______ _______
CLK | | | | | | | |
*CE ____| |_______| |_______| |_______| |_____
*WE _______ __________________________
| |
|_______________________________|
Addr -------------------------------------------------------------------
Data RA0 | WA0 | WA1 | RA1 | RA2
| | | |
-------------------------------------------------------------------
ANOTHER OPTION:
-- Use one of Brian's multi-cycle schemes, and make the data path to the
SRAM
double/triple wide to maintain bandwidth.
Hope one of these suggestions helps...
Bob Elkind, FPGA design consulting, etc. etc. etc.
eteam@aracnet.com
Louis Zhang wrote:
>
> Hi Brian,
>
> Thanks for your response.
>
> Unfortunately, the cycle time needs to be 30MHz as well,
> and I cannot use a 60MHz or 90MHz clock to produce the
> 30MHz clock.
>
> Thanks.
>
> -----------------------
> Louis Zhang
> lzhang@eecg.toronto.edu
>
Brian's excellent suggestions on using multi-cycle acccess were
"snipped" - be
> > > The problem of the asynchronous SRAM is with its write operation, where
> > > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > > address (and data) is stable, and deasserted ('1') "shortly" before the
> > > address (and data) changes. In other words, R/Wn has to be deasserted
> > > ('1') when address or data change.
> > >
> > > The desired waveform looks like this:
> > >
> > > CLK= 30MHz
> > >
> > > _______ _______ ________ ________
> > > CLK | | | | | | | |
> > > ____| |_______| |_______| |______| |_____
> > >
> > > R/Wn _______ ______ _______________________________
> > > | | | |
> > > |__________| |_________|
> > >
> > > Addr -------------------------------------------------------------------
> > > RA0 | WA0 | WA1 | RA1 | RA2
> > > | | | |
> > > -------------------------------------------------------------------
Article: 13433Conceptually, Xilinx's guided par seems like a great way to reduce par run time when making a small change (read "bug fix") in a design. But when I tried it recently, it actually introduced new bugs into my design. I was using it in the mode where you copy the n-1 version design information into the project clipboard in Design Mangler and use that as guide files for version n. After a few iterations of this, I started seeing various problems in testing the hardware. Doing a "clean slate" par of the same EDIF cleared up the problems. Has anyone else had problems with guided par? I would really like to cut down on the par run times (2+ hours on a SPARC for several of my 4028XL designs) when just adding an inverter or whatnot. And, yes, I know that: (a) designs "should" be synchronous (these are) (b) I can add an inverter in EPIC (and remember to add it to the schematic also) Thanks, -Steve GrossArticle: 13434
Peter Alfke wrote: > <snipped> > All our devices are getting much faster. Don't worry, be happy. > Assuming that the power dissipation problems can be solved, the other major barrier to high-speed FPGA operation is I/O limitations. Any chance of getting differential I/O with LVPECL or LVDS levels from FPGAs this century? I could really use an FPGA or even CPLD with LVDS I/O options right now. Low power, so much easier to terminate, and ground bounce becomes a virtual non-issue. Tom Burgess -- Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 13435
Hi Bob,
Thanks a lot for your help. I was actually thinking about exactly
the same thing last night. :-)
However, when using the CLK for *CE, there is a little problem with the
read cycle. The Xilinx FPGA needs to register the read data and the
register is clocked by the delayed version of "CLK" (CLK go through a
Clock Buffer). We call this CLK_delayed.
During a read cycle, we deassert the *CE ('1') when clock goes to high,
then data starts to be tri-stated after a CE high to High Z (Tchhz)
delay. The data goes through an input pad delay (Tipad) and setup time
(Tsetup). If the (Tipad + Tsetup + Tchhz) < Clock Skew, where the clock
skew is the from CLK to CLK_delayed, then we will have a hold time
problem.
Xilinx has some nice feature which allows you to add some additional
delay (full delay or partial delay) at the input path. Unfornately,
the read data also needs to be clocked by a custom ASIC which does not
have this feature. So the clock skew, if is big (6ns?), can be less
than (Tipad + Tsetup + Tchhz). If this happens, then the read cycle
won't work.
Thanks for any suggestions again.
-----------------------
Louis Zhang
lzhang@eecg.toronto.edu
On Wed, 2 Dec 1998, bob elkind wrote:
> Louis,
>
> 1. Data doesn't (usually) need to be stable *before* the assertion of
> /WE,
> just needs to be stable (setup time) before *deassertion* of /WE.
>
> Many Async SRAM data sheets are misleading.
>
> 2. Use CLK for *CE. Assume CLK is generated off-chip.
>
> 3. Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.
>
> 4. ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
> CLK->Q->pin min prop delay through, which should be greater than
> the SRAM's min HOLD time req. for ADDR/DATA/*WE.
>
> 5. ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi)
> width,
> less max prop delay of CLK->Q->pin path through FPGA.
>
> Pick a combination of SRAM speed and FPGA speed that suits timing
> constraints 4 and 5. SRAM will need to be faster than 15nS access,
> but these are readily available in 1Mb ($3 US, roughly) and 4Mb
> sizes.
>
> 6. Make sure you "manage" onboard interconnect skews for
> CLK/ADDR/DATA/*WE.
>
> 7. If you want to read from SRAM, don't assert *WE. *WE is the output
> of
> a normal on-chip FF, clocked by CLK(^), with same timing as
> ADDR/DATA.
>
> _______ _______ _______ _______
> CLK | | | | | | | |
> *CE ____| |_______| |_______| |_______| |_____
>
> *WE _______ __________________________
> | |
> |_______________________________|
>
> Addr -------------------------------------------------------------------
> Data RA0 | WA0 | WA1 | RA1 | RA2
> | | | |
> -------------------------------------------------------------------
>
> ANOTHER OPTION:
>
> -- Use one of Brian's multi-cycle schemes, and make the data path to the
> SRAM
> double/triple wide to maintain bandwidth.
>
> Hope one of these suggestions helps...
>
> Bob Elkind, FPGA design consulting, etc. etc. etc.
> eteam@aracnet.com
>
>
> Louis Zhang wrote:
> >
> > Hi Brian,
> >
> > Thanks for your response.
> >
> > Unfortunately, the cycle time needs to be 30MHz as well,
> > and I cannot use a 60MHz or 90MHz clock to produce the
> > 30MHz clock.
> >
> > Thanks.
> >
> > -----------------------
> > Louis Zhang
> > lzhang@eecg.toronto.edu
> >
>
> Brian's excellent suggestions on using multi-cycle acccess were
> "snipped" - be
>
> > > > The problem of the asynchronous SRAM is with its write operation, where
> > > > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > > > address (and data) is stable, and deasserted ('1') "shortly" before the
> > > > address (and data) changes. In other words, R/Wn has to be deasserted
> > > > ('1') when address or data change.
> > > >
> > > > The desired waveform looks like this:
> > > >
> > > > CLK= 30MHz
> > > >
> > > > _______ _______ ________ ________
> > > > CLK | | | | | | | |
> > > > ____| |_______| |_______| |______| |_____
> > > >
> > > > R/Wn _______ ______ _______________________________
> > > > | | | |
> > > > |__________| |_________|
> > > >
> > > > Addr -------------------------------------------------------------------
> > > > RA0 | WA0 | WA1 | RA1 | RA2
> > > > | | | |
> > > > -------------------------------------------------------------------
>
>
Article: 13436
Well, then you might have to resort to tricks. There at one time was an App Note
from Xilinx on clock doubling. If you look in an older data book you should be able
to find it.(My interpretation is below) The caveat is that while frequency is
double, high time pulse width may not be constant as it depends on routing delays.
Anyways, use the rising edge of clk for address/data, and falling edge of 2xCLK for
R/W.....
_____ _____ _____ _____ _____ _____
___
CLK ____| |_____| |_____| |_____| |_____| |_____| |_____|
__ __ __ __ __ __ __ __ __ __ __ __
__
2xCLK ____| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__|
|
____ __________ __________ __________ __________ __________ __________
__
A/D
____{}__________{}__________{}__________{}__________{}__________{}__________{}__
_______ _____ _________________
______________________________
R/W |_____| |_____| |_____|
Cycle Write1 Write2 Read1 Write3 Read2 Read3
As for the clock doubler.....
___________________________________________
| |
| |\ |
| | \ _________ |
O-------------------| |O---| D Q |-----O
| _____ | / | |
|______| | |/ | |
| | | |
| XOR |----o---------|> |
30Mhz Clock _______________| | | | |
|_____| | |_____R___|
| Reset_______|
|______________________________________>
2xCLK
Be very careful to ensure that the high pulse meets your device minimum pulse width
requirements. The sum of the Flip-Flop Clock-to-Q delay, route delay Q-to-Xor, and
prop delay through Xor, total of these three will be your 2xCLK high time.
Hope that helps :-)
Louis Zhang wrote:
> Hi Brian,
>
> Thanks for your response.
>
> Unfortunately, the cycle time needs to be 30MHz as well,
> and I cannot use a 60MHz or 90MHz clock to produce the
> 30MHz clock.
>
> Thanks.
>
> -----------------------
> Louis Zhang
> lzhang@eecg.toronto.edu
>
> > Louis Zhang wrote:... snip ...
> >
> > > The problem of the asynchronous SRAM is with its write operation, where
> > > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > > address (and data) is stable, and deasserted ('1') "shortly" before the
> > > address (and data) changes. In other words, R/Wn has to be deasserted
> > > ('1') when address or data change.
> > >
> > > The desired waveform looks like this:
> > >
> > > CLK= 30MHz
> > >
> > > _______ _______ ________ ________
> > > CLK | | | | | | | |
> > > ____| |_______| |_______| |______| |_____
> > >
> > > R/Wn _______ ______ _______________________________
> > > | | | |
> > > |__________| |_________|
> > >
> > > Addr -------------------------------------------------------------------
> > > RA0 | WA0 | WA1 | RA1 | RA2
> > > | | | |
> > > -------------------------------------------------------------------
> > >
> >
> >
> >
> > --
> > Brian C. Boorman
> > Harris RF Communications
> > Rochester, NY 14610
> > XYZ.bboorman@harris.com
> > <Remove the XYZ. for valid address>
> >
> >
> >
> >
--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 13437
1. Do the
math
(arithmetic)
on the
data input
vs. CLK
input
setup/hold
requirements.
With the
Xilinx
FPGA you
might be
OK.
For the
2nd "load"
on the
SRAM data
output
(the
ASIC):
2. Get the
registered
data from
the Xilinx
FPGA
rather
than
directly
from
the SRAM
(consumes
IO
pins),
OR
3. Add
discrete
registers
on the
board to
clock the
SRAM DOUT.
(e.g.
'646,
'373,
'374,
etc.).
This would
work for
Data going
to FPGA
as well as
ASIC.
For the
diehard
engineer:
Route the
CLK
daisy-chain
to
First:
the FPGA
and ASIC
CLK inputs
for
registering
the SRAM
DOUT
Second:
the SRAM
*CE inputs
(add xx nS
of trace
delay to
provide
timing
margin)
Third:
the FPGA
CLK input
for
registering
the
Addr/*WE/Write.Data
(add xx nS
of trace
delay to
provide
timing
margin)
Trace
delay is
appr.
1.8-2.0 nS
per foot.
Don't know
what that
is in
meters or
furlongs.
** If this
is a
school
project**,
I really
hope we
aren't
"doing
your
homework
for you";
part of
your
training
is to
explore
all the
possibilities
and
consider
the
strengths
and
weaknesses
of
each/all.
-- Bob
Elkind,
yada yada
yada FPGA
design
consulting,
etc.
eteam@aracnet.com
Louis
Zhang
wrote:
>
> Hi Bob,
>
> However, when using the CLK for *CE, there is a little problem with the
> read cycle. The Xilinx FPGA needs to register the read data and the
> register is clocked by the delayed version of "CLK" (CLK go through a
> Clock Buffer). We call this CLK_delayed.
>
> During a read cycle, we deassert the *CE ('1') when clock goes to high,
> then data starts to be tri-stated after a CE high to High Z (Tchhz)
> delay. The data goes through an input pad delay (Tipad) and setup time
> (Tsetup). If the (Tipad + Tsetup + Tchhz) < Clock Skew, where the clock
> skew is the from CLK to CLK_delayed, then we will have a hold time
> problem.
>
> Xilinx has some nice feature which allows you to add some additional
> delay (full delay or partial delay) at the input path. Unfornately,
> the read data also needs to be clocked by a custom ASIC which does not
> have this feature. So the clock skew, if is big (6ns?), can be less
> than (Tipad + Tsetup + Tchhz). If this happens, then the read cycle
> won't work.
>
> Louis Zhang
> lzhang@eecg.toronto.edu
>
> On Wed, 2 Dec 1998, bob elkind wrote:
>
> > Louis,
> >
> > 1. Data doesn't (usually) need to be stable *before* the assertion of /WE,
> > just needs to be stable (setup time) before *deassertion* of /WE.
> >
> > Many Async SRAM data sheets are misleading.
> >
> > 2. Use CLK for *CE. Assume CLK is generated off-chip.
> >
> > 3. Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.
> >
> > 4. ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
> > CLK->Q->pin min prop delay through, which should be greater than
> > the SRAM's min HOLD time req. for ADDR/DATA/*WE.
> >
> > 5. ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi) width,
> > less max prop delay of CLK->Q->pin path through FPGA.
> >
> > Pick a combination of SRAM speed and FPGA speed that suits timing
> > constraints 4 and 5. SRAM will need to be faster than 15nS access,
> > but these are readily available in 1Mb ($3 US, roughly) and 4Mb sizes.
> >
> > 6. Make sure you "manage" onboard interconnect skews for CLK/ADDR/DATA/*WE.
> >
> > 7. If you want to read from SRAM, don't assert *WE. *WE is the output of
> > a normal on-chip FF, clocked by CLK(^), with same timing as ADDR/DATA.
> >
> > _______ _______ _______ _______
> > CLK | | | | | | | |
> > *CE ____| |_______| |_______| |_______| |_____
> >
> > *WE _______ __________________________
> > | |
> > |_______________________________|
> >
> > Addr -------------------------------------------------------------------
> > Data RA0 | WA0 | WA1 | RA1 | RA2
> > | | | |
> > -------------------------------------------------------------------
Article: 13438
1. Do the math (arithmetic) on the data input vs. CLK input setup/hold
requirements. With the Xilinx FPGA you might be OK.
For the 2nd "load" on the SRAM data output (the ASIC):
2. Get the registered data from the Xilinx FPGA rather than directly
from the SRAM (consumes IO pins), OR
3. Add discrete registers on the board to clock the SRAM DOUT.
(e.g. '646, '373, '374, etc.). This would work for Data going
to FPGA as well as ASIC.
For the diehard engineer:
Route the CLK daisy-chain to
First: the FPGA and ASIC CLK inputs for registering the SRAM DOUT
Second: the SRAM *CE inputs (add xx nS of trace delay to provide timing margin)
Third: the FPGA CLK input for registering the Addr/*WE/Write.Data (add xx nS of trace delay to provide timing margin)
Trace delay is appr. 1.8-2.0 nS per foot. Don't know what that is in meters or furlongs.
** If this is a school project**, I really hope we aren't "doing your homework for you"; part of your training is to explore all
the possibilities
and consider the strengths and weaknesses of each/all.
-- Bob Elkind, yada yada yada FPGA design consulting, etc.
eteam@aracnet.com
Louis Zhang wrote:
>
> Hi Bob,
>
> Thanks a lot for your help. I was actually thinking about exactly
> the same thing last night. :-)
>
> However, when using the CLK for *CE, there is a little problem with the
> read cycle. The Xilinx FPGA needs to register the read data and the
> register is clocked by the delayed version of "CLK" (CLK go through a
> Clock Buffer). We call this CLK_delayed.
>
> During a read cycle, we deassert the *CE ('1') when clock goes to high,
> then data starts to be tri-stated after a CE high to High Z (Tchhz)
> delay. The data goes through an input pad delay (Tipad) and setup time
> (Tsetup). If the (Tipad + Tsetup + Tchhz) < Clock Skew, where the clock
> skew is the from CLK to CLK_delayed, then we will have a hold time
> problem.
>
> Xilinx has some nice feature which allows you to add some additional
> delay (full delay or partial delay) at the input path. Unfornately,
> the read data also needs to be clocked by a custom ASIC which does not
> have this feature. So the clock skew, if is big (6ns?), can be less
> than (Tipad + Tsetup + Tchhz). If this happens, then the read cycle
> won't work.
>
> Thanks for any suggestions again.
>
> -----------------------
> Louis Zhang
> lzhang@eecg.toronto.edu
>
> On Wed, 2 Dec 1998, bob elkind wrote:
>
> > Louis,
> >
> > 1. Data doesn't (usually) need to be stable *before* the assertion of /WE,
> > just needs to be stable (setup time) before *deassertion* of /WE.
> >
> > Many Async SRAM data sheets are misleading.
> >
> > 2. Use CLK for *CE. Assume CLK is generated off-chip.
> >
> > 3. Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.
> >
> > 4. ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
> > CLK->Q->pin min prop delay through, which should be greater than
> > the SRAM's min HOLD time req. for ADDR/DATA/*WE.
> >
> > 5. ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi) width,
> > less max prop delay of CLK->Q->pin path through FPGA.
> >
> > Pick a combination of SRAM speed and FPGA speed that suits timing
> > constraints 4 and 5. SRAM will need to be faster than 15nS access,
> > but these are readily available in 1Mb ($3 US, roughly) and 4Mb sizes.
> >
> > 6. Make sure you "manage" onboard interconnect skews for CLK/ADDR/DATA/*WE.
> >
> > 7. If you want to read from SRAM, don't assert *WE. *WE is the output of
> > a normal on-chip FF, clocked by CLK(^), with same timing as ADDR/DATA.
> >
> > _______ _______ _______ _______
> > CLK | | | | | | | |
> > *CE ____| |_______| |_______| |_______| |_____
> >
> > *WE _______ __________________________
> > | |
> > |_______________________________|
> >
> > Addr -------------------------------------------------------------------
> > Data RA0 | WA0 | WA1 | RA1 | RA2
> > | | | |
> > -------------------------------------------------------------------
> >
> > ANOTHER OPTION:
> >
> > -- Use one of Brian's multi-cycle schemes, and make the data path to the SRAM
> > double/triple wide to maintain bandwidth.
> >
> > Hope one of these suggestions helps...
> >
> > Bob Elkind, FPGA design consulting, etc. etc. etc.
> > eteam@aracnet.com
Article: 13439Thanks for Bob and Brian for your excellent suggestions. We are sort of beyond our duty doing a test board for the 300,000-gate ASIC that two of us designed for a Grad course ealier this year. So now this is really the homework that we assigned for ourselves that bears NO grade/mark. :-) The real product that this ASIC will go into later on has a higher frequency clock that we can use for the programmable clock to mask the R/Wn that I mentioned. However, the IC tester that this simple board will be tested with does not have this luxury. Again, thanks for your kind helps. ----------------------- Louis Zhang lzhang@eecg.toronto.eduArticle: 13440
> We are try to build an Xilinx FPGA to read and write to an asynchronous
> SRAM (due to the design requirement, we can only use asynchronous SRAM,
> not synchronous SRAM nor ZBT SRAM)
>
> The problem of the asynchronous SRAM is with its write operation, where
> the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> address (and data) is stable, and deasserted ('1') "shortly" before the
> address (and data) changes. In other words, R/Wn has to be deasserted
> ('1') when address or data change.
I've never found a really clean and simple way to do this. Here is the
way I think about that problem area.
You have to generate a write pulse from the clock signal and various
gates. The leading edge has to be after the new address gets there and
the trailing edge has to go away before the address changes.
There are two ways to make that pulse - from the front half of the clock
signal or the back half.
If you are working with the front half of the clock, then you have to
make sure there is enough delay in the write pulse to meet the address
setup time but not so much delay that the trailing edge overlaps into
the next cycle. This gets into minimum delays so expect to do some
handwaving. If you put in too much delay the max times will bite you
on the trailing edge. This works OK if you have lots of time.
If you want to use the back half of the clock pulse, then you need an
early (gate delay or two) verison of the clock to work with. A real
delay line might work to push the front half late into the clock cycle
but trying to do that with gates doesn't work for me. One of the PLL
clock chips would probably work too.
My straw man is to use a PAL for the master clock generator on the
board. I call the outputs of the PAL preClock so I can call the signal
inside the FPGA (after the clock buffer) clock. That seems to be the
easiest way for me to think about things. I compute all times relative
to "clock" and that seems to result in the least arithmetic.
Suppose you use one of the PAL terms as an AND gate with the enable
signal coming from a FF in the FPGA to make your write pulse. The
write pulse will terminate when the clock goes into the FPGA so you
have all of the FPGA delay less the PAL skew for hold time. That's
clearly positive. You have to get the write enable to the PAL very
early in the cycle - you start with a half cycle but you have to
subtract off the PAL delay and the FPGA clock-out delay.
You may be able to push the PAL into the FPGA. I describe it
externally since I think that makes things easier to understand
or describe. Remember that you have to keep the skew low. I do
the wiring and placement by hand, making sure that some "smart"
software doesn't through away the dummy CLB that I need to make
the timing on the preClock paths match the timing on the write
pulse.
--
These are my opinions, not necessarily my employers.
Article: 13441Good luck on your project. As you can tell, there is usually more than one way to solve a design problem such as this. You have an advantage in that you are (presumably) building only one device, and you can hand-tweak the FPGA on-chip routing/timing, and select fast or slow parts as needed. The wind is at your backs, so to speak. Your odds of success are good, especially with the care for details that you have obviously given. -- Bob Elkind Louis Zhang wrote: > > Thanks for Bob and Brian for your excellent suggestions. > > We are sort of beyond our duty doing a test board for the > 300,000-gate ASIC that two of us designed for a Grad course > ealier this year. So now this is really the homework that we > assigned for ourselves that bears NO grade/mark. :-) > > The real product that this ASIC will go into later on has a > higher frequency clock that we can use for the programmable > clock to mask the R/Wn that I mentioned. However, the IC tester > that this simple board will be tested with does not have this > luxury. > > Again, thanks for your kind helps. > > ----------------------- > Louis Zhang > lzhang@eecg.toronto.eduArticle: 13442
In article <3665BC30.BCBC08B7@hia.nrc.ca>,
Tom Burgess <tom.burgess@hia.nrc.ca> wrote:
>Peter Alfke wrote:
><snipped>
>> All our devices are getting much faster. Don't worry, be happy.
>Assuming that the power dissipation problems can be solved, the
>other major barrier to high-speed FPGA operation is I/O limitations.
>Any chance of getting differential I/O with LVPECL or LVDS levels from
>FPGAs this century? I could really use an FPGA or even CPLD with
>LVDS I/O options right now. Low power, so much easier to terminate,
>and ground bounce becomes a virtual non-issue.
I would love to see fast PECL I/O on an SRAM-based FPGA. I recently did a
600MHz ECL/FPGA design, and would have loved to have been able to rid of all
those 'ELT22s and 'ELT21s.
What is LVPECL and LVDS? I've heard of LVTTL, but not any of these others.
Are they ASIC I/O options or something? I think the I/O really needs to be
ECL or PECL since there are well established ECL logic families, ECL
oscillators/PLLs and ECL A/D and D/A converters. There must be some way to
make ECL-compatiable drivers and receivers with MOSFETs on CMOS FPGAs. They
did it with GaS.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 13443Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm having problems configuring the device. I'm using a master serial configuration (I'm trying to use the XChecker cable now, and a serial PROM later). When I first power up the board, if I probe the CCLK pin with a scope, I get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak. When I try to configure the device using an XChecker cable, the frequency of the CCLK signal goes up to something like 7 MHz, even though I'm using slow configuration. When I hit the PROG button on the board, the frequency goes back to it's normal rate (900 kHz). Of course, the hardware debugger says something is wrong when I try to program the device! Is there something I'm doing wrong? Could the device be bad? I really need help on this one! Thanks, OH (Forward reply via email too please)Article: 13444
Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm having problems configuring the device. I'm using a master serial configuration (I'm trying to use the XChecker cable now, and a serial PROM later). When I first power up the board, if I probe the CCLK pin with a scope, I get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak. When I try to configure the device using an XChecker cable, the frequency of the CCLK signal goes up to something like 7 MHz, even though I'm using slow configuration. When I hit the PROG button on the board, the frequency goes back to it's normal rate (900 kHz). Of course, the hardware debugger says something is wrong when I try to program the device! Is there something I'm doing wrong? Could the device be bad? I really need help on this one! Thanks, OH (Forward reply via email too please)Article: 13445
Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm having problems configuring the device. I'm using a master serial configuration (I'm trying to use the XChecker cable now, and a serial PROM later). When I first power up the board, if I probe the CCLK pin with a scope, I get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak. When I try to configure the device using an XChecker cable, the frequency of the CCLK signal goes up to something like 7 MHz, even though I'm using slow configuration. When I hit the PROG button on the board, the frequency goes back to it's normal rate (900 kHz). Of course, the hardware debugger says something is wrong when I try to program the device! Is there something I'm doing wrong? Could the device be bad? I really need help on this one! Thanks, OH (Forward reply via email too please)Article: 13446
For use with Xchecker, you must set the FPGA to Slave serial. What you are seeing is the contention of two drivers both trying to drive the CCLK pin. In article <3665FA54.F6F59967@gel.ulaval.ca> Olivier Hebert <hebert01@gel.ulaval.ca> writes: >Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm >having problems configuring the device. I'm using a master serial >configuration (I'm trying to use the XChecker cable now, and a serial >PROM later). You will need Master serial with the PROM, Slave serial for xchecker. The codes are 111 and 000, so you can tie the 3 mode pins together, and select the two modes with one jumper. > >When I first power up the board, if I probe the CCLK pin with a scope, I >get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak. This is the FPGA driving the CCLK pin 900KHz, and the xchecker is driving a continuous low (or high) and is in contention. >When I try to configure the device using an XChecker cable, the >frequency of the CCLK signal goes up to something like 7 MHz, even >though I'm using slow configuration. This is Xchecker driving the CCLK, but it is in contention with the FPGA which is still driving the pin (with 900KHz). The configuration clock rate only affects Serial Master, and since the XChecker is designed to run with the FPGA in serial slave, it can use any rate it likes, upto about 10MHz. > When I hit the PROG button on the >board, the frequency goes back to it's normal rate (900 kHz). Of course, >the hardware debugger says something is wrong when I try to program the >device! Xchecker has gone IDLE, and the chip is still trying to send CCLKs to a prom that isn't there. >Is there something I'm doing wrong? Could the device be bad? I really >need help on this one! >Thanks, Your Welcome. Philip FreidinArticle: 13447
You need to use master serial for prom, slave serial for the xchecker. One connects all the mode bits to '1' the other is all '0'. CCLK is sourced by the FPGA for master serial and by the xchecker for slave serial. You need to disconnect the xchecker when programming from a PROM to avoid contention. The configuration speed only effects the master serial's CCLK. Olivier Hebert wrote: > Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm > having problems configuring the device. I'm using a master serial > configuration (I'm trying to use the XChecker cable now, and a serial > PROM later). > > When I first power up the board, if I probe the CCLK pin with a scope, I > get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak. > When I try to configure the device using an XChecker cable, the > frequency of the CCLK signal goes up to something like 7 MHz, even > though I'm using slow configuration. When I hit the PROG button on the > board, the frequency goes back to it's normal rate (900 kHz). Of course, > the hardware debugger says something is wrong when I try to program the > device! > > Is there something I'm doing wrong? Could the device be bad? I really > need help on this one! > > Thanks, > > OH > > (Forward reply via email too please) -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13448
In article <36657B63.280B640F@xilinx.com>, peter.alfke@xilinx.com wrote: > shailbains007@my-dejanews.com wrote: > > What factors would determine the *lowest* clock frequency that can > > drive a given digital circuit? [..] > > All Xilinx FPGAs and CPLDs are completely static, except for the serial > configuration input to the XC3000 devices, where CCLK must not be parked > Low. I seem to recall that the 4K series has a miminum frequency of operation, if you use any embebbed kind of RAM. > Hope this helps. Bye > Peter Alfke, Xilinx Applications Matija In chaos all things are possible. Matija Milostnik, RDHW, IskraTEL, Ljubljanska 24a, SI-4000 Kranj, Slovenia Tel: +386 64 27 2125, Fax: +386 64 221 552, Email: milostnik@iskratel.si www.IskraTEL.si: Building the world of telecommunications -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13449
On Xilinx 4K there is also the restriction on the high time for the CLB RAM write clock (max 1ms). Depending on your design, this may put a lower limit on the clock frequency. The restriction is due to excessive power dissipation while the clock is high. Peter Alfke wrote: > shailbains007@my-dejanews.com wrote: > > > What factors would determine the *lowest* clock frequency that can > > drive a > > given digital circuit? (I can very well understand the existence of a > > an > > upper limit.) > > > > Circuits using static logic have no lower limit for their clock > frequency ( but even at a low frequency, the clock edges must be crisp > with short transition times, below 10 nanoseconds). > Some logic stores information not in static latches, but on capacitors, > where the data will leak away. DRAMs are the most widespread users of > this space-saving method. In that case, there is a max time between > refreshing clocks. > In non-DRAMs, such dynamic logic is rare, so most logic can be clocked > at zero frequency. > All Xilinx FPGAs and CPLDs are completely static, except for the serial > configuration input to the XC3000 devices, where CCLK must not be parked > Low. > Hope this helps. > > Peter Alfke, Xilinx Applications -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z