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
Park Chan Ik <park@iris.snu.ac.kr> writes:
>Hello.
>I am using FLEX10K100 from Altera for a prototyping
>board.
>While designing the board, I am wondering which I/O pins I should select
>for the external I/O. I mean I would like to place two FIFOs and memory
>controller on the FLEX10K100 and fix the I/O pins on PCB like the
>following.
>While the memory controller and FIFOs are fixed, blocks are variable
>depending on some application.
> |||||||
> ---------------------------------------------
> | |memory controller| |
> | ----------------- |
> | | |
> I/O --|------- ------- ------- ------ ------|-- I/O
> --|FIFO |-|block1|-|block2|-..|block3|--|FIFO||--
> --|------ ------- ------- ------ ------|--
> | |
> |____________________________________________|
>I think the placement and routing of later designed blocks are dependent
>on the glue logics.
>Can you give me any advice for selecting I/O pins for external interface
>logic?
Howdy...
I chose to fix pins for a similar reason. The FPGA for my
design was chosen to be flexible (reconfigurable), so it seemed
silly for me to have Xilinx tools pick the pin placement.
Therefore, I just fixed them myself in a somewhat logical manner
(like you did above) and hoped for the best. So far, things
have worked out great. However, I should note that currently,
I'm only at about 50% usage or so. Things might get tighter
near high usages.
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 10101Antoine Lecerf wrote: > > Thank you very much to all of those who answered my question. I give you > more details about my problem. > > My SRAM is an 512k8 extern asychronous SRAM and my FPGA is a > XC4025E-2. > At each front edge of my clock, I put the adress and data but > also my Write Enable signal. I disable my Write Enable signal on the back > edge > of my clock. > But to write data inside the SRAM, I must wait a stable address, and > that's why > I need to introduce a delay (between 4 and 30 ns) to my Write Enable > signal. > > I know that it's better to introduce a delay with some extern components. > But in > our case, for many reasons we prefer to introduce this delay inside the > FPGA. > > My addresses are calculate on clock before that I put them outside the > FPGA. > > To introduce my delay, I probably have two possibilities but I'm bot sure: > > 1) I can configure my address outputs with a fast slew rate and my Write > Enable signal with a slow slew rate. > ---> The delay wil be probably too short. > > 2) I can use a clock buffer (BUFGS) on my Write Enable signal to introduce > > this delay. > > Give me yours ideas, please... > > Thanks! > Antoine Try one of these: 1) As far as I know you can place your address~ & data-flipflops directly into your IOB's. The write_enable-signal can be generated elsewhere, but take care: The delay depends on place&route , so it may vary. Check before usage! 2) Assuming that your clockfrequency is somehow greater than 60 ns, get an oscillator with 2*fclk. Downscaling the frequency inside the fpga is very SIMPLE! Additional cost : 1 FF -> 0.5 CLB! With this solution you have more than one cylce for writing, and so you are no longer in the need for an asycnhronous-design-style. Hope this helps, HagenArticle: 10102
FCCM '98 Top 10 Predictions for FCCMs in 2003
---------------------------------------------
This was a semi-official, semi-serious, fully-enjoyable activity, during
the
unscheduled Thursday evening at FCCM '98 earlier this month. (FCCM is
the IEEE Symposium on Field-Programmable Custom Computing Machines,
arguably
the main conference on reconfigurable computing. <http://www.fccm.org>)
It's a reprise of the FCCM '96 Top 10 Predictions for 2001. We
shamelessly
stole the idea from the CANDE Workshop of the IEEE Circuits and Systems
Society.
(Though we've been a lot less serious than they were.)
After many of us enjoyed a bit of beer, 41 participants broke into five
groups,
which each came up with ten predictions. Each group presented their
predictions
to all, and each participant then voted for their favorite five.
Some are serious, some decidedly not. But all in all it's an
interesting
sampling of what's on the minds of leading people in reconfigurable
computing.
Moderated and compiled by Mike Butts. Results certified by the
accounting firm
of Dewey, Cheatham and Howe, Philip Frieden presiding.
Thanks to Virtual Computer Corp. <http://www.vcc.com> for all the
beer!!!
(...and the room, the yummies and the splendid prizes)
And especially to all the participants!
1. We will *still* hate the tools. (27 votes: two thirds!)
2. 90% of embedded systems on a chip will contain FPGA logic for
FCCM-type usage. (14)
3. FPGAs in FCCMs will have hardwired functional units (ALU, FPU,
MPY, PCI...). (12)
4. At FCCM '03, Mark Shand will give a paper on interfacing to the
Hubble Telescope using FCCMs. (11)
5. At FCCM '03, there will still be a high number of gratuitous
architectures presented. (10)
6. FCCMs will place and route themselves. (9)
7. The predominant FCCM language will be Java++ ... but someone
will still be doing C to FCCM. (9)
8. Splash II apps will still appear at FCCM '03. (9)
9. A "savior" killer app for FCCMs will appear. (8)
10. We will see the first conscious FCCM. (8)
11. CAD will be the killer app for FCCM. (8 votes)
12. It didn't fit.
For all 50 predictions from the five groups, and for the 1996 list,
please visit the FCCM '98 web pages at <http://www.fccm.org>.
--Mike
Article: 10103
We have something on the order of 10,000 lines of VHDL, which synthesizes
down to about 85-90% of an Altera 10K70 (the -3 speed grade is our target
part). Now, it is neither possible nor necessary for the entire design to
meet the 25 MHz system clock requirement after place and route. This is
because the most complex stuff only needs to process data at half system
clock speed.
Therefore, we partition off the slow-speed blocks and desire to connect the
"CE" inputs to all the "DFFE" flip flops to a 12.5 MHz (sys clock divided by
2) clock enable signal. Typical code for a clock enable looks something
like this:
PROCESS(aclr_n,sys_clk)
BEGIN
IF aclr_n='0' THEN --asynchronous clear
clear_proc;--clear all signals this process is responsible for
ELSIF RISING_EDGE(sys_clk)THEN
IF clk_ena='1' THEN
IF s_reset='1' THEN --synchronous reset
clear_proc;--clear all signals this process is responsible
for
ELSE
CASE command IS
...
...
...
END CASE;
END IF;--end of s_reset
END IF;--end of clock enable condition
END IF;--end of sys_clk and aclr_n block
END PROCESS;
We have run the design through both Galileo Extreme 4.2.2, and Synplify
3.0b. There are a couple of problems with the synthesis of this technique.
1.) The main problem is that the synthesis tools do not seem to honor the
clock enable qualifier as a special type of signal. Apparently they treat
it as another combinatorial input available for logic minimization into the
"D" input of the DFFE. This then spoils the special nature of the CE input
as a high frequency clock gate, since it is driven by a combinatorial signal
which is not going to settle out in one system clock cycle. Indeed,
counters do not count, state machines do not sequence, and CRC generators do
not CRC.
2.) Even if one could get the synthesizer to connect the CE inputs for a
given component in the design to the desired clock enable signal, there is
no simple way to specify to the synthesis tools that the combinatorial paths
within that region only need to meet 12.5 MHz. Hence, they try to optimize
the entire design for a flat 25 MHz requirement, wasting resources in the
slow speed regions unnecesarily, which brings down the high speed regions
from what they could be.
The last, loathsome, resort would be to re-write the design to directly
instantiate DFFE registers of various widths, and directly connect the CE
inputs, in netlist fashion, but, please (shudder) don't let it come to that!
Surely this must be a common issue in VHDL/FPGA design. In the schematic
domain, the solution would be simple: wire the CE inputs to the clock
enable signal all the way down the hierarchy. The absence of a similarly
simple solution for VHDL synthesis would seem to defeat the purpose of the
high level description.
Any insight into this would be greatly appreciated.
Thanks,
Tom Meagher (last name pronounced "mar", don't ask why...)
tomm@icshou.com
Article: 10104
Rickman wrote:
> Antoine Lecerf wrote:
> >
> > My SRAM is an 512k8 extern asychronous SRAM and my FPGA is a
> > XC4025E-2.
> > At each front edge of my clock, I put the adress and data but
> > also my Write Enable signal. I disable my Write Enable signal on the back
> > edge
> > of my clock.
> > But to write data inside the SRAM, I must wait a stable address, and
> > that's why
> > I need to introduce a delay (between 4 and 30 ns) to my Write Enable
> > signal.
> >
> > I know that it's better to introduce a delay with some extern components.
> > But in
> > our case, for many reasons we prefer to introduce this delay inside the
> > FPGA.
> >
> > My addresses are calculate on clock before that I put them outside the
> > FPGA.
> >
> > To introduce my delay, I probably have two possibilities but I'm bot sure:
> >
> > 1) I can configure my address outputs with a fast slew rate and my Write
> > Enable signal with a slow slew rate.
> > ---> The delay wil be probably too short.
> >
> > 2) I can use a clock buffer (BUFGS) on my Write Enable signal to introduce
> >
> > this delay.
> >
> > Give me yours ideas, please...
> >
> > Thanks!
> > Antoine
>
> --
> What you are trying to do is very clear. We are trying to tell you that
> what you want to do is not a good idea and most likely won't work. If
> you give me an idea of the timing data, I could tell you a little better
> if it will work or not. What is your clock freq? What is the write
> enable min time for the SRAM? What is the setup time for the address and
> data for the SRAM?
>
> As I said in an earlier post, I tried to do what you are describing,
> writing to an external async SRAM in a single clock cycle. If the clock
> cycle is anywhere near the cycle time of the SRAM, you won't be able to
> do it without violating spec'd timing requirements. It may work, it may
> work over temp and voltage. But Xilinx won't guarantee it to work. No
> one specs their parts with tight minimum delays and it is the minimum
> delay that you will need to depend on, not the maximum.
>
> But with some timing data, I can tell you if it is feasible.
>
> Rick Collins
>
> rickman@XYwriteme.com
>
> remove the XY to email me.
--
My clock frequency is about 15 MHz.
The write enable min time of my SRAM is 20 ns.
The setup time for the adress and data (on the SRAM) is 0 ns. I just need a
stable adress before I put my write enable.
My VHDL code to avoid glitch on my write enable is:
where nWE_in is set high when I want to write and nWE_out is send to the Write
enable of my SRAM.
____ ____ ____ ____
CLK | | | | | | | |
---| |----| |----| |----| |
nWE_out
---| |----| |----| |----| |
|____| |____| |____| |____|
I would probably use this code with two inversers on nWE_out and with a
set_dont_touch attribute is my Synopsys script in order that the compiler don't
remove these two inverters!
entity sram_int is
port(
CLK : in std_logic;
RESET : in std_logic;
nWE_in : in std_logic;
nWE_out : out std_logic
);
end sram_int;
architecture RTL of sram_int is
signal Q1, Q2 : std_logic;
begin
--
synch_HL1 : process(CLK,RESET)
begin
if (RESET = '1') then
Q1 <= '1';
elsif (CLK'event and CLK = '0') then
if (nWE_in = '0') then
Q1 <= not(Q1);
end if;
end if;
end process synch_HL1;
--
synch_LH1 : process(CLK,RESET)
begin
if (RESET = '1') then
Q2 <= '1';
elsif (CLK'event and CLK = '1') then
if (nWE_in = '0') then
Q2 <= not(Q2);
end if;
end if;
end process synch_LH1;
--
nWE_out <= not(Q1 xor Q2);
end RTL;
\\\\\\\\\\\\\\\\\\\\\\\\\
Antoine
lecerf00@gel.ulaval.ca
Article: 10105In article <Es2AIu.Htt@world.std.com>, jhallen@world.std.com (Joseph H Allen) wrote: > > This situation is not so easy for synchronous rams either. It sure would be > nice if the next generation of FPGAs would fix this problem by providing > "clock output pads" which give a guarenteed (and controllable) relationship > between the output clock and any clocked pads which use the same clock. > They also need a final gate for this case of generating the WE signal for > asynchronous SRAMs. But given that this is not yet available: > I was just giving this thread a passing glance to this point. I have used FPGAs and EPLDs to control DRAM and asynchronous SRAM at very near their top speed. 60nS fast page mode DRAM has (had at the time) a 45nS fast page mode access time. I used a 63MHz clock and three cycles for 47.6nS. I do 20nS asynchronous SRAM at 26MHz with very little effort using an Altera EPF8636ARC208-3. I could do 40MHz with the same design, but the Fibre Channel data rate is 26.5625. One solution is to use the clock going into the FPGA as the clock to the synchronous SRAM rather than trying to have the clock output by the FPGA. I didn't even have to do that in the above case, but I did use asynchronous SRAM. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10106
In article <3543F53D.7098F433@iris.snu.ac.kr>, Park Chan Ik <park@iris.snu.ac.kr> wrote: > > Hello. > I am using FLEX10K100 from Altera for a prototyping board. > While designing the board, I am wondering which I/O pins I should select > for the external I/O. I mean I would like to place two FIFOs and memory > controller on the FLEX10K100 and fix the I/O pins on PCB like the > following. While the memory controller and FIFOs are fixed, blocks are > variable depending on some application. If Maxplus 2 has any major limitation, this is it. That ability to tell the compiler to optimize the pin assignment for more than one design. I doubt anyone else has it either though. I used the Xilinx XACT 5 a few years ago. Compared to that, Maxplus 2 was a dream to use. I have suggest to Altera that something along these lines are needed. With FPGAs and in-circuit programmable EPLDs, vendors claim the design and board layout can be started before the pal contents is complete. That in itself shows that such a need exists. Also, many vendors have different capacity devices that are "pin compatible", yet they are not always route compatible. The ability to tell the compiler to pick a pinout that would work with any pin compatible device would be helpful. Now to your point. Here is how I solve the problem. Do your design and compile it. Do all your simulation and debugging. If you have more than one concept in mind, do the same for each iteration, using identical pin names for each. Once you have the final design for each case, use the "OPTIONS - Back-Annotate Project" and select "Chip, Pin & Device" to make the pin assignments permanent for one design. You can delete the logic cell assignments that say "LOCATION" to make it easier to work with. Now try those pin assignments for the other designs to see if they will fit. You can do this by cutting and pasteing in the .ACF file. The latest versions of Maxplus 2 (V8.1 or later) handle this properly. Earlier versions did not always unless you use the Maxplus 2 editor, which I don't like or use. If you "lock down" the macrocell assignments you will probably get a message during fitting that tells you a fit could not be found, and then you will be given a chance to unlock logic cells, then minimal pins, then all pins. Keep doing this back and forth until you find a pinout that will work. You might want to group your signals manually to enable easier board routing. I have found that lately with Maxplus 2 that I can pick the pin assignments to meet my needs (simplify board routing). This was the one case I found the Xilinx tools superior. Prior to compiling I could tell XACT to put a pin in a particular quadrant or on a particular side of the chip. Altera has so far failed to implement all such requests for this type of feature and I have made it many times. Altera has "cliques" but they don't even come close to being good enough to arrange pins easily for board routing. What you will need to watch out for is that the fitter will insert a logic cell as a buffer to allow a signal to route. That will affect your timing. I look through the .RPT file (report file). You cannot turn off soft buffer insertion for FLex10k devices, so there is no way to stop this that I know of. If I see any logic cells in the .RPT file with a name like _LC_ I change my design until they go away. I don't use VHDL and this last step may not be practical if you do. It can be done in AHDL if you do not use functions. I find I can get more logic to run faster in a slower part with AHDL than others can with VHDL. It is not any more work or any more difficult, it is just different, and non-portable. VHDL spends more time simulating and optimizing, I spend more time doing the original design. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10107
Antoine Lecerf wrote:
> My clock frequency is about 15 MHz.
> The write enable min time of my SRAM is 20 ns.
> The setup time for the adress and data (on the SRAM) is 0 ns. I just need a
> stable adress before I put my write enable.
>
> My VHDL code to avoid glitch on my write enable is:
>
> where nWE_in is set high when I want to write and nWE_out is send to the Write
> enable of my SRAM.
> ____ ____ ____ ____
> CLK | | | | | | | |
> ---| |----| |----| |----| |
> nWE_out
> ---| |----| |----| |----| |
> |____| |____| |____| |____|
>
> I would probably use this code with two inversers on nWE_out and with a
> set_dont_touch attribute is my Synopsys script in order that the compiler don't
> remove these two inverters!
...snip...
--
I think you will be able to write to the SRAM in your application. You
have a 67 ns clock and a 20 ns SRAM. This gives you lots of room to play
with, which is what you need. Again, let me restate that this is the
worst possible solution to this problem, but it will work if you pay a
lot of attention to the best case timing as well as the worse case
timing.
You can try two different ways to generate the write strobe with the
correct timing. One would be to output the address as fast as possible
on the rising edge of the clock while using a delayed, inverted clock to
drive the WE. The trick is to get a consistent delay on the WE. The
other is to generate a splinter pulse on an edge of the clock using a
delay.
Information that I received from Xilinx (I believe it is available on
the web on in some of their app notes) says to use 25% of the max time
delay as the min delay. You need a very small delay between the address
and the WE. You could latch the address in the IOBs (giving the shortest
possible clock to output delay) and invert the clock through a CLB along
with any gating logic before running it out through an IOB to make the
WE. Let the timing analyser tell you what the delay is on the WE. As
long as it is three or four ns longer than the clock to output time for
the address, you should be OK. You don't need to worry about the max
delay on the WE unless it gets larger than 30 ns (very unlikely). You
will need to clock the incoming WE on the falling edge of the clock to
make this work. nWE_in can only change when the clock is low!
nWE_in
------| |---------|
|___________________| |__________
clock
---| |----| |----| |----| |----|
|____| |____| |____| |____| |___
|
--->| |<--- Logic delay > 0
nWE_out |
----------| |----| |--------------| |-
|____| |____| |____|
VHDL:
nWE_out <= not ((not nWE_in) and clock);
A second approach would be to generate the WE on the rising edge of the
clock by ORing the clock with a delayed version of the clock. This would
need to use a well defined delay since the max and min delays of the
FPGA are not compatible with your timing. To get 20 ns min, you would
have 80 ns max. Your pulse must be limited to about 50 ns or so to be
useful. To set the delay, I would use one of the methods suggested by
others here. But they will have to be external to the FPGA. So this
approach may not work for you.
I don't think your code is adding anything to the solution. Basically it
is regenerating an inverted, delayed version of the clock. Just use the
VHDL to make the logic controlling the SRAM. You will need to use timing
constraints to make the circuit work. I don't beleive there is any
standard way to force the timing in VHDL.
Rick Collins
rickman@XYwriteme.com
remove the XY to email me.
Article: 10108Greetings Alternate Verilog FAQ" version 6.1 is released. http://www.comit.com/~rajesh/verilog/faq/alt_FAQ.html Updates: 1. Information about Verilog-AMS (Analog and Mixed Signal) added 2. Information about free PC simulators modified. Rajesh -- Rajesh Bawankule | Checkout http://www.comit.com/~rajesh/verilog/ Hardware Engineering Manager | for Verilog FAQ Comit Systems Inc. | 3375, Scott Blvd, #330 | Phone : (408)-988-2988 Santa Clara, CA 94054 | Fax : (408)-988-2133 ----------------------------------------------------------------------------- -------------------------------------------------------------------- Posted using Reference.COM http://WWW.Reference.COM FREE Usenet and Mailing list archive, directory and clipping service --------------------------------------------------------------------Article: 10109
In article <3549c9ac.75134257@news.netcomuk.co.uk>, z80@ds2.com (Peter) writes: > As I think I have mentioned, it would not be hard to write a little > command-line program, C or even AWK, which edits the .mcs file as > required. Yes, but... Is there a location that corresponds to the flip-reset-ploarity bit and is it documented? [if so, where] -- These are my opinions, not necessarily my employers.Article: 10110
Tom Meagher wrote: > > We have something on the order of 10,000 lines of VHDL, which synthesizes > down to about 85-90% of an Altera 10K70 (the -3 speed grade is our target > part). Now, it is neither possible nor necessary for the entire design to > meet the 25 MHz system clock requirement after place and route. This is > because the most complex stuff only needs to process data at half system > clock speed. > > Therefore, we partition off the slow-speed blocks and desire to connect the > "CE" inputs to all the "DFFE" flip flops to a 12.5 MHz (sys clock divided by > 2) clock enable signal. Typical code for a clock enable looks something > like this: > > PROCESS(aclr_n,sys_clk) > BEGIN > IF aclr_n='0' THEN --asynchronous clear > clear_proc;--clear all signals this process is responsible for > ELSIF RISING_EDGE(sys_clk)THEN > IF clk_ena='1' THEN > IF s_reset='1' THEN --synchronous reset > clear_proc;--clear all signals this process is responsible > for > ELSE > CASE command IS > ... > ... > ... > END CASE; > END IF;--end of s_reset > END IF;--end of clock enable condition > END IF;--end of sys_clk and aclr_n block > END PROCESS; > > We have run the design through both Galileo Extreme 4.2.2, and Synplify > 3.0b. There are a couple of problems with the synthesis of this technique. > > 1.) The main problem is that the synthesis tools do not seem to honor the > clock enable qualifier as a special type of signal. Apparently they treat > it as another combinatorial input available for logic minimization into the > "D" input of the DFFE. This then spoils the special nature of the CE input > as a high frequency clock gate, since it is driven by a combinatorial signal > which is not going to settle out in one system clock cycle. Indeed, > counters do not count, state machines do not sequence, and CRC generators do > not CRC. > > 2.) Even if one could get the synthesizer to connect the CE inputs for a > given component in the design to the desired clock enable signal, there is > no simple way to specify to the synthesis tools that the combinatorial paths > within that region only need to meet 12.5 MHz. Hence, they try to optimize > the entire design for a flat 25 MHz requirement, wasting resources in the > slow speed regions unnecesarily, which brings down the high speed regions > from what they could be. > > The last, loathsome, resort would be to re-write the design to directly > instantiate DFFE registers of various widths, and directly connect the CE > inputs, in netlist fashion, but, please (shudder) don't let it come to that! > > Surely this must be a common issue in VHDL/FPGA design. In the schematic > domain, the solution would be simple: wire the CE inputs to the clock > enable signal all the way down the hierarchy. The absence of a similarly > simple solution for VHDL synthesis would seem to defeat the purpose of the > high level description. > > Any insight into this would be greatly appreciated. > > Thanks, > Tom Meagher (last name pronounced "mar", don't ask why...) > tomm@icshou.com Synthesis tools I used (Synopsys, Compass RIP) have a command to specify multicycle paths. With synopsys, the command is 'set_multicycle_path'. Are you sure that your tool doesn't have such a common feature ? This command answer your 2 questions since clk_ena is out of the multicycle path. jean-MarcArticle: 10111
allard jean-marc wrote in message <3544D8ED.25D66CD1@hol.fr>...
>Tom Meagher wrote:
>>
...
...
>>
>
>Synthesis tools I used (Synopsys, Compass RIP) have a command to specify
>multicycle paths.
>With synopsys, the command is 'set_multicycle_path'. Are you sure that
>your tool doesn't have such a common feature ?
>This command answer your 2 questions since clk_ena is out of the
>multicycle
>path.
>
>jean-Marc
Yes, this is true, there is a multi-cycle path command for Galileo and
Synplify(see the excerpts
below), but I interpret this to be on a signal by signal, or register by
register basis,
not for an entire instantiated sub-component, several levels down in the
hierarchy, which
might have hundreds of signals and registers.
And, even if one specified all the signals in the sub-component as
multi-cycle,
which seems rather tedious, I don't see how this forces the clock enables to
be connected
to the synthesized DFFE's. Am I missing something here?
[EXCERPT FROM GALILEO EXTREME TECHNOLOGY GUIDE]
Support for Multicycle Path
Use the following syntax to specify Multicycle path constraints to
Galileo Extreme:
set a multicycle path:
set_multicycle_path -from <> -to <> -value <value> ->
delete a multicycle path:
set_multicycle_path -from <> -to <> -unset ->
options for multicycle path:
set_multicycle_path [options] <from> <to> <value>
[-setup] setup time
[-hold] set hold time
[-rise][fall] set relative to falling edge of clock
[-src_clk] name of source clock
[-dest_clk] name of destination clock
[-to <list>] list of source points
[-from <list>] list of end points
[-value <integer>] number of cycles
[-unset] unset constraint
For Example:
set_multicycle_path -setup -rise -from u2.reg_rxdatardy -to
u2_regframingerr -value 2
This example sets the clock cycle (for setup and clock rising) between
u2.reg_rxdatardy and u2.regframingerr to 2 cycles.
Paths that you flag as multicycle will not be optimized for timing and
are not reported
as critical paths.
Copyright (c) 1998 Exemplar Logic Inc. All rights reserved.
[END OF GALILEO EXCERPT]
[EXCERPT FROM SYNPLIFY HELP FILE]
define_multicycle_path { -from <register_or_input> | -to
<register_or_output> } <num_clock_cycles>
Use the "define_multicycle_path" timing constraint to specify that
certain
paths use multiple clock cycles and that Synplify should not try to
report
those paths as a violation of the design frequency timing goal.
"define_multicycle_path" tells Synplify to give an extra clock cycle to
all paths from or to a register.
You may use the "-from" option or the "-to" option, but not both
simultaneously
for "define_multicycle_path".
Example
Assume you have a multiplier that multiplies "signal_a" together with
"signal_b"
and puts the result into "signal_c". Assume "signal_a" and "signal_b" are
outputs of registers "register_a" and "register_b" respectively.
On clock cycle 1, a state machine enables an "input_enable" signal to
load
"signal_a" into "register_a" and "signal_b" into "register_b". At the
beginning
of clock cycle 2 the multiply begins. After 2 clock cycles (now that the
multiply is finished), on clock cycle 4, the state machine enables an
"output_enable" signal to load the result of the multiply ("signal_c")
into an output register ("register_c").
In this example our design frequency goal is 50 MHz (20 ns) and the
multiply
takes 35 ns, but we have given it 2 clock cycles. Synplify would
normally
report this 35 ns path as a timing violation because it is more than the
20
ns clock cycle timing goal.
To avoid Synplify reporting the paths for the multiply as timing
violations,
use the following timing constraints:
#paths from register_a use 2 clock cycles
define_multicycle_path -from register_a 2
#paths from register_b use 2 clock cycles
define_multicycle_path -from register_b 2
An alternative approach is to give the output register and specify that
paths to
the output register use multiple clock cycles:
#paths to register_c use 2 clock cycles
define_multicycle_path -to register_c 2
Copyright (c) 1994-1997 Synplicity, Inc. All rights reserved.
[END OF EXCERPT FROM SYNPLIFY HELP FILE]
Article: 10112Hi, The deadline for submitting an abstract for the PhD forum at DAC is Friday May 1st. More details are provided below: Objective: The objective of the Ph.D. forum at DAC is to strengthen the ties between academic research and industry. Participating students will show posters that describe their Ph.D. thesis work. This session will provide the students an opportunity to receive feedback on their work. It also previews academic work-in-progress to the DA community. Eligibility: Submissions are open to all PhD students who are within 1 or 2 years of completing their thesis. Students who completed their thesis this academic year are also welcome to participate. Submit a one-page abstract, plus an approved thesis proposal or a published paper. When/Where: This poster session will be during the first part of the SIGDA member meeting, Tuesday, June 16 in the early evening. *Non-SIGDA members are encouraged to attend*. More Info: For more information about the Ph.D. forum at DAC, please visit http://www.cs.washington.edu/homes/soha/forum/ , or send email to daforum@cs.washington.eduArticle: 10113
In article <354386EE.59E0A319@gel.ulaval.ca>#1/1, Antoine Lecerf <lecerf00@gel.ulaval.ca> wrote: > My SRAM is an 512k8 extern asychronous SRAM and my FPGA is a > XC4025E-2. > At each front edge of my clock, I put the adress and data but > also my Write Enable signal. I disable my Write Enable signal on the back > edge > of my clock. > But to write data inside the SRAM, I must wait a stable address, and > that's why > I need to introduce a delay (between 4 and 30 ns) to my Write Enable > signal. I agree with all those who are stating that it is not a good idea to do this. One way I have used to implement a delay in the past is to use an unbonded pad (UPAD) tied to both an input buffer and an output buffer. Route the signal you want to delay through this path. The problem with this is you can not accuratly predict the delay that will be generated. But it will add a delay. BTW, the design where I added the delay, it did not work. Ryan Herbst rherbst@verilink.com -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10114
I have an application where I want to operate on either a 62.5MHz or 125MHz clock rate sample stream. I am concerned that although FPGA manufacturers quote internal operation of counters etc at 166MHz, that packaging parasitics may limit the I/O data rates. Could anyone that has used FPGAs with high I/O data rates comment on what they would consider would be the highest data rate that, say, a 3.3V Altera Flex 10k130 could handle on its I/O pins? I am considering having a 62.5MHz clock and a 125MHz clock. Then having a 62.5MHz clock rate data stream multiplexed by 2 on-board where operations on the data are performed at 125MHz. Doubling the clock rate on-board reduces the required logic by a factor of four for my application. Thanks for any assistance. Email replies to me as well. Dave Hawkins. dwh@ovro.caltech.eduArticle: 10115
In article <6i2aug$f4s$1@supernews.com>, "Tom Meagher" <tomm@icshou.com> wrote: > > We have something on the order of 10,000 lines of VHDL, which synthesizes > down to about 85-90% of an Altera 10K70 (the -3 speed grade is our target > part). Now, it is neither possible nor necessary for the entire design to > meet the 25 MHz system clock requirement after place and route. This is > because the most complex stuff only needs to process data at half system > clock speed. > > Therefore, we partition off the slow-speed blocks and desire to connect the > "CE" inputs to all the "DFFE" flip flops to a 12.5 MHz (sys clock divided by > 2) clock enable signal. Tom, A couple of points. First, the 10k logic elements use one of the 4 lookup table inputs for the clock enable (1998 Databook page 35). The I/O elements have true clock enables from global signals (1998 databook page 49), but the logic elements do not. Since you thyen only have 3 LUT inputs, you are more likely to have cascaded logic elements feeding the DFFEs. A non-global reset or preset takes another LUT input if you are using it. Under certain conditions global presets take a LUT input. Using both clear and preset always uses a LUT input. Having a synchronous load capability also uses a LUT input. The carry output uses one also. Some combinations are mutually exclusive. In effect the clock enable for a 10k logic element is really just a 4th input to the lookup table which would then imply a fifth [not shown] input, feedback from the Q output of the DFF. I/O elements can only have a single signal feed the D input though so that probably won't help. Since a logic element clock enable isn't global, there are routing delays associated with it. Using schematic entry wouldn't help. You are already telling Maxplus 2 to use the clock enable, you are just expecting too much from it. You need to look in the .RPT file and see how the DFFEs are synthesized. My opinion is that this is a case where AHDL would give you better results. Does VHDL retain the symbolic names in the .RPT file? (AHDL does if you do not use funtions) If you have some high speed signals and some that are static or lower speed you can cause the slower ones to have the longer delay paths by coding the preceeding logic cells yourself. I have been asking Altera to provide a way to do this at a higher level for several years, but so far nothing. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10116
I am too lazy to look this up in the Xilinx data book, but yes they are fixed locations. I used to have a post-it pad on the wall here with the addresses written down, and what values to change them to. There are about 4 locations to change, IIRC. On the assumption that the filesize and general layout of the .mcs file is always the same, one could do a very simple text hacking program to do the edit. Otherwise, one would need to load the intel hex image into RAM, edit it, and write out another intel hex file. This need to edit the .mcs file is not the only apparently simple thing which Xilinx don't seem to have catered for. Another one is the -s switch on Makebits, needed to enable the on-chip oscillator. The P&R software (or XMAKE) should determine, from the flattened XNF netlist, that the oscillator symbol has been used, and tell Makebits about this. Instead, you have to edit the .mak file manually otherwise the oscillator won't run. >> As I think I have mentioned, it would not be hard to write a little >> command-line program, C or even AWK, which edits the .mcs file as >> required. > >Yes, but... Is there a location that corresponds >to the flip-reset-ploarity bit and is it documented? >[if so, where] Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 10117
Hiya, I know this is the TOTALLY wrong newsgroup for this message but perhaps someone could point me in the right direction anyhow. I am after the connector for a Fiber Optic Link Digital Audio Interface for the output cables from a Sony DAT to be connected into. Anyone know where I can get them? Thanks!!Article: 10118
HI: .How can we recognize the nets from the Netlist? Is it possible that in the layout the gates are named ? The program we use is Design Framework II. The Hit-kit version is 2.40. The process is Cell/Block Ensemble & Preview ;we start from Composer Schematic and finish with the layout.Then we get extracted view.And from this view we make: Tools->Simulation->Other. Simulation->Netlist/Simulate(with Spice). The Netlist that we get begins with a list like this(is much longer): * net 0 = gnd! * net 0 = gnd! * net 1 = /o<21> * net 2 = /160 * net 3 = /44 * net 4 = /822 * net 5 = /463 * net 6 = /766 ... * net 927 = /60 * net 928 = /782 * net 929 = /331 * net 930 = /634 * net 931 = /275 * net 932 = /578 Here we can recognize the input and output nets , but not the internal ones. That's what we would like to get.(For instance: net 500 = / w<23>)Article: 10119
Rickman <spamgoeshere1@yahoo.com> writes: > > I would say that you are barking up the wrong tree. I assume you are > trying to write to an external async SRAM in a single clock cycle. This > is not something that anyone will recommend unless you can use external > logic to generate a gating signal. > > You should never try to generate a quantifiable delay inside of an FPGA. > The specs on the part are not that well defined. For example, you said > you wanted about 4 ns. Xilinx says the minimum delay should be estimated > at 25% of the maximum delay (and even this is not guaranteed). So to be > confident that you will get 4 ns over the range of all variables, you > would need to design in a delay of 16 ns. If you can tolerate this much > maximum delay, your design might work. But you can see the problem. > > It would be much better to either generate the timing signals to the > SRAM in external components that are built to give known time delays. Or > you could use a synchronous SRAM. Or use a two up clock and generate the > signals synchronously. > ... or use a synchronous SRAM. On the Xilinx Web site there is a brand new XCell article by Brad Taylor on interfacing XL parts to Micron's SDRAM's. It can be applied to sync SRAM's with little modifications. -Arrigo -- Arrigo Benedetti o e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 < > phone: (626) 395-3695 Pasadena, CA 91125 / \ fax: (626) 795-8649Article: 10120
Cartoons for the engineering community can be found on: http://www.TheTechSide.com/ -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10121
In article <6i33lk$b23$1@nnrp1.dejanews.com>#1/1, lnwolf@amaroq.com wrote: > > I agree with all those who are stating that it is not a good idea > to do this. One way I have used to implement a delay in the past is > to use an unbonded pad (UPAD) tied to both an input buffer and an > output buffer. Route the signal you want to delay through this > path. The problem with this is you can not accuratly predict the > delay that will be generated. But it will add a delay. > Ryan, I once did a test like that. I connected a bi-directional pin in output mode to ground. I used feedback from the pin to clock an internal register. This was after I had spent many many hours trying to find why something didn't work as I expected it to. The register being clocked by the exteranl pin did toggle, though the pad showed very little sign of activity. My conclusion was that the inductance of the bonding wire, lead frame, etc. was enough to allow the pad itself to rise above the TTL threshold long enough to clock the internal register. It also means that feeding a signal out to a pad and taking feedback from there may not insure that the feedback signal is coincident with the external signal. Something that might be obvious as I say this, but wasn't then. I wanted the feedback to be slowed down by the external capacitance just as the external devices would see it. That isn't what happened. With 50-100pF of external capacitance the internal signal was several nanoseconds faster, making the design not work properly. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10122
In article <6i37k8$ci4@gap.cco.caltech.edu>#1/1, "Dave Hawkins" <dwh@ovro.caltech.edu> wrote: > > I have an application where I want to operate on either > a 62.5MHz or 125MHz clock rate sample stream. > > I am concerned that although FPGA manufacturers quote > internal operation of counters etc at 166MHz, that packaging > parasitics may limit the I/O data rates. > > Could anyone that has used FPGAs with high I/O data rates > comment on what they would consider would be the highest > data rate that, say, a 3.3V Altera Flex 10k130 could handle > on its I/O pins? > > I am considering having a 62.5MHz clock and a 125MHz clock. > Then having a 62.5MHz clock rate data stream multiplexed by > 2 on-board where operations on the data are performed at 125MHz. > Doubling the clock rate on-board reduces the required logic by > a factor of four for my application. > > Thanks for any assistance. Email replies to me as well. > > Dave Hawkins. > > dwh@ovro.caltech.edu > > Dave, I ahve used 5 volt 10k devices at 100MHz. It will depend on the external capacitive loading and the setup and hold requirements of your external logic. You can certainly run the 10k part that fast internally. You may also find that having two cloks like that causes a problem. If the data is ever to be passed between them you would be better off to just use the faster clock and disable the slower registers every other clock cycle. The logic required to pass data between to clocks of unknown phase, and your will be regardless of what precautions you take, is fairly complex compared to using a single flip flop set to toggle as a clock enable to registers running fast. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10123
In article <6i2aug$f4s$1@supernews.com>#1/1, "Tom Meagher" <tomm@icshou.com> wrote: > > We have something on the order of 10,000 lines of VHDL, which synthesizes > down to about 85-90% of an Altera 10K70 (the -3 speed grade is our target > part). Now, it is neither possible nor necessary for the entire design to > meet the 25 MHz system clock requirement after place and route. This is > because the most complex stuff only needs to process data at half system > clock speed. > > Therefore, we partition off the slow-speed blocks and desire to connect the > "CE" inputs to all the "DFFE" flip flops to a 12.5 MHz (sys clock divided by > 2) clock enable signal. Typical code for a clock enable looks something > like this: > Tom, I read your message again this morning. At 12.5MHz and 25MHz what you are doing should be a breeze. I do it at 60-100MHz frequently, even with slower speed grades (*see note). Look at your .RPT file and trace one of the logic elements that don't work. You could even post the relavent parts. You will probably find that the clock enable is going through several layers of combinatorial logic, and/or the rest of the data to the LUT is also. * Note: The speed listed in the Altera databook is for 16 bit synchronous counters. No tricks like lookahead carries are used to achieve those numbers. I have several times gotten higher speeds, validated by their simulator and timing analyser, by quite a bit. Scott Taylor - DSP Fibre Channel Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 10124
I check 10k ALTERA 5v on the speed of 140 MHz. Works!! But I did all design in AHDL and in some critical places need to define CLB placement manualy. CLIQUE some times does not help. Good luck Lev Razamat - PHASECOM Inc.
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