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
there is a
uniform(seed1,seed2,rand_v);
in ieee
It will generate a random number each time it is called. the seed values we
keep in a small text file, and using standard io calls, read, increment, and
save the numbers each time the simulation is started. This gives a random
stream of data each time a restart is done.
"FGreen" <fastgreen2000@yahoo.com> wrote in message
news:d31579b8.0410281239.7e6805d9@posting.google.com...
> Back ground info : Using Modelsim in Windows environment, using
> Verilog.
>
> I'm trying to generate a random number that's different each time
> $random is called. Not knowing much about DOS/windows environment, I
> need help passing in wallclock information from the command line (in a
> does batch file).
>
> Doing
>
> dos prompt> vsim +SEED='time' ...
>
> and using in the testbench
>
> if (!($value$plusargs("SEED=%d", rand_seed))
> ...
>
> doesn't work because the wallclock time isn't passed in correctly. I
> don't want to use the same starting seed each time the simulation is
> run, either. I'll, of course, save the seed so that I can reproduce
> the bugs.
>
> How do I get around this problem?
> How do you use random data pattern in your test bench?
>
> I don't have an option of using unix (or unix-like shell in
> windows)...
>
> Thanks in advance.
Article: 75226Simon Peacock wrote: > > If current peaks are smaller.. than the PSU is smaller => smaller can be > more efficient. Also if current doesn't die down instantaneously but decays > due to L & C, then in theory, circuits which idle between clocks would draw > more power than a circuit which gathers all the idles at the end and just > sits there as there is no capacitors to charge and discharge on every clock. > (Just a theory!) These currents spikes are never seen by the PSU. They are so short that you have to have decoupling capacitors on your board (and very close to the chips) to smooth them out so they don't cause havoc with all the chips on the board. > All the rest valid points.. all made it the thesis too... > And you did hit the nail on the head with traffic cops.. That's the big > chunk of true async HDL. Sync runs at the speed of the slowest device async > goes as fast as possible. so traffic lights are on every corner. > The other big chunk is the variable delay used set minimum times for signal > transportation or for work to happen. That's why FPGA's don't work.. no > async delays. you would be forced to use constant delays and that breaks the > async rules. > > Also I believe that a flip flop that is clocked but does nothing, still > consumes more power than a flip-flop doing nothing. (i.e. no clock) > CMOS is all about changes not static conditions. The 'average' for async > systems doing the same task as sync systems is longer static periods. > > then there aren't any clock buffers in an async system, no need, in large > systems, they can form a significant chunk of power. But this is apples and oranges, both have leaves and need to be peeled before you make juice. Async may not have clock trees and a clocked idle FF may use more power than one with no clock, but an async circuit has to propagate the clock through a delay circuit that is guaranteed to take more time than the logic circuit. That certainly will take power * the number of circuits. So which is more, apples or oranges? > Your right about different architectures too... As a sync designer I > synchronise everything. its the mind set... but to design async you need to > think async... and its not easy.. all the rules are thrown out for a new > set. Async is all about just in time delivery. I am not clear. I agree that the rules are very different. But I am not sure the rules have been discovered yet. If all the circuits are in a straight line, then each circuit is triggered by the one before it and you have no timing problems. If you have any parallel paths, you need a way to align the data at the end. Or you have to use a different sort of structure. Having all the different circuits idle except the one being clocked is wasteful of the silicon. You should be able to keep all of the silicon busy if possible by the instruction being executed. > And, of course, there are some async designs that draw more power than sync > designs... but as time goes by they will get better. and you have a silicon > overhead for all the extra 'timing' circuits 20% maybe .. and in reality, > today, silicon is more expensive than power. for the manufacturer that is. But it is the chip user that pays for the silicon *and* the power. So they determine the relative importance. Are there any clear, concise guidelines written up anywhere for how to design async circuits. I wouldn't mind reading about that in my spare time (if I can find any). -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75227
Marc Kelly <marc@redbeard.demon.co.uk> wrote in message news:<clrqdi$3vs$1$8300dec7@news.demon.co.uk>... > Hello, I was wondering if someone with a bit more experience in these > things than me could maybe explain this.. > > I have a design that has to have two versions, with very minor > functional differences and one of them works, the other hes very messed > up clocks, with clocks missing or very badly screwed up... Both have the > same pin constaints and timings. As far as i can see the only major > difference between the two in the place and route of them is as follows... > > For X board (NON working..) > > | clk_ret_i | BUFGMUX0S| No | 2172 | 0.272 | 1.188 > | > +-------------------------+----------+------+------+------------+-------------+ > | cclk_in_aux | BUFGMUX4S| No | 33 | 0.069 | 1.157 > | > +-------------------------+----------+------+------+------------+-------------+ > | cclk_in_g | BUFGMUX3S| No | 3 | 0.000 | 1.136 > | > +-------------------------+----------+------+------+------------+-------------+ > | dclk_g | BUFGMUX6S| No | 10 | 0.007 | 1.150 > | > > For Y board (working..) > > | clk_ret_i | BUFGMUX2S| No | 2171 | 0.272 | 1.188 > | > +-------------------------+----------+------+------+------------+-------------+ > | cclk_in_aux | BUFGMUX4S| No | 33 | 0.029 | 1.167 > | > +-------------------------+----------+------+------+------------+-------------+ > | cclk_in_g | BUFGMUX7P| No | 5 | 0.138 | 1.161 > | > +-------------------------+----------+------+------+------------+-------------+ > | dclk_g | BUFGMUX6S| No | 10 | 0.005 | 1.111 > | > Odd .... Given the above BUFGMUX locations, I think Board X should be working and Y should have bad clocks. Board Y BUFGMUXs for cclk_in_g and dclk_g are using adjacent BUFGMUXs which is not correct. -Vikram.Article: 75228
I think the PSU does see the short spikes... just over a longer period. I don't know if there's more than just PHd Thesis about at the moment. Philips had something.. but it might be in house and I'm sure there's tons of stuff if you ask the right person. The stuff I have is getting old to old really.. but it is still relevant as the field doesn't seem to have moved very far in the last 8 years. When you talk about keeping all the silicon busy.. that's a fairy tail. When did your last design use every bit of silicon for every clock? I don't believe they do.. any piece of complex silicon doesn't use itself 100% all the time. My own designs work in bursts... I even build a simple FIFO using shift registers which swap out ever second cycle.. so they're not used all the time .. even less than 50%. Other parts only use one clock in 8. quite in efficient really.. but I only have one 16 MHz clock so that's the way it is. I don't know how much async logic would help for designs like this.. mainly because the input is sync and the output too.. but that's just one app. "... but an async circuit has to propagate the clock ..." You are thinking sync again.. Async circuits don't have a clock.. so nothing to propagate they rely on hand shakes, delays and just in time. Clocks are forbidden except in cross over designs (that the sync designer hasn't got his head around yet!) There are tricks to aligning parallel paths.. known by sorcerers and magicians everywhere but not witch doctors. And yes.. chip users do pay for power and silicon. But as long as they pay, the suppliers don't complain. so they decide what's best for them.. and more chips per wafer is a big plus on the balance sheet. Of course this rule doesn't so much apply to Intel. but they have a bonus of windows.. where you can never have too much power. Simon "rickman" <spamgoeshere4@yahoo.com> wrote in message news:41831590.A7F2D61@yahoo.com... > Simon Peacock wrote: > > > > If current peaks are smaller.. than the PSU is smaller => smaller can be > > more efficient. Also if current doesn't die down instantaneously but decays > > due to L & C, then in theory, circuits which idle between clocks would draw > > more power than a circuit which gathers all the idles at the end and just > > sits there as there is no capacitors to charge and discharge on every clock. > > (Just a theory!) > > These currents spikes are never seen by the PSU. They are so short that > you have to have decoupling capacitors on your board (and very close to > the chips) to smooth them out so they don't cause havoc with all the > chips on the board. > > > > All the rest valid points.. all made it the thesis too... > > And you did hit the nail on the head with traffic cops.. That's the big > > chunk of true async HDL. Sync runs at the speed of the slowest device async > > goes as fast as possible. so traffic lights are on every corner. > > The other big chunk is the variable delay used set minimum times for signal > > transportation or for work to happen. That's why FPGA's don't work.. no > > async delays. you would be forced to use constant delays and that breaks the > > async rules. > > > > Also I believe that a flip flop that is clocked but does nothing, still > > consumes more power than a flip-flop doing nothing. (i.e. no clock) > > CMOS is all about changes not static conditions. The 'average' for async > > systems doing the same task as sync systems is longer static periods. > > > > then there aren't any clock buffers in an async system, no need, in large > > systems, they can form a significant chunk of power. > > But this is apples and oranges, both have leaves and need to be peeled > before you make juice. Async may not have clock trees and a clocked > idle FF may use more power than one with no clock, but an async circuit > has to propagate the clock through a delay circuit that is guaranteed to > take more time than the logic circuit. That certainly will take power * > the number of circuits. So which is more, apples or oranges? > > > Your right about different architectures too... As a sync designer I > > synchronise everything. its the mind set... but to design async you need to > > think async... and its not easy.. all the rules are thrown out for a new > > set. Async is all about just in time delivery. > > I am not clear. I agree that the rules are very different. But I am > not sure the rules have been discovered yet. If all the circuits are in > a straight line, then each circuit is triggered by the one before it and > you have no timing problems. If you have any parallel paths, you need a > way to align the data at the end. Or you have to use a different sort > of structure. Having all the different circuits idle except the one > being clocked is wasteful of the silicon. You should be able to keep > all of the silicon busy if possible by the instruction being executed. > > > > And, of course, there are some async designs that draw more power than sync > > designs... but as time goes by they will get better. and you have a silicon > > overhead for all the extra 'timing' circuits 20% maybe .. and in reality, > > today, silicon is more expensive than power. for the manufacturer that is. > > But it is the chip user that pays for the silicon *and* the power. So > they determine the relative importance. > > Are there any clear, concise guidelines written up anywhere for how to > design async circuits. I wouldn't mind reading about that in my spare > time (if I can find any). > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75229
Simon Peacock wrote: > I think the PSU does see the short spikes... just over a longer period. > > I don't know if there's more than just PHd Thesis about at the moment. > Philips had something.. but it might be in house and I'm sure there's tons > of stuff if you ask the right person. Philips have released some devices over the years. Now obsolete, but quite impressive given the process/power results, is an OTP Telephony 80C51 variant : http://www.semiconductors.philips.com/cgi-bin/pldb/pip/P87CL888T -jgArticle: 75230
Hi all,
The following VHDL code does not synthesize using XST 6.2.03:
----- start of fragment
-- The challenge is to define an entity that replicates
-- an input port (push button) to an output port (LED),
-- without declaring them in the entity's ports.
library ieee, unisim;
use ieee.std_logic_1164.all, unisim.vcomponents.all;
entity toplevel is
-- wire input button to output LED
-- without using a port declaration
end entity toplevel;
architecture arch of toplevel is
signal BUTTON : std_logic;
signal LED : std_logic;
signal sig_led : std_logic;
signal sig_button : std_logic;
attribute LOC : string;
attribute LOC of BUTTON : signal is "P22";
attribute LOC of LED : signal is "P20";
component OBUF is
port (O: out std_ulogic; I: in std_ulogic);
end component OBUF;
component IBUF is
port (O: out std_ulogic; I: in std_ulogic);
end component IBUF;
begin
button_buf : component IBUF port map(O => sig_button , I => BUTTON);
led_buf : component OBUF port map(O => LED , I => not
sig_led);
sig_led <= sig_button;
end architecture arch;
----- end of fragment
The following problem seems to be causing this. When a signal is used
that does not correspond to a top-level in/out port, it seems that XST
makes the following inferences:
(1) if a signal does not drive anything, it doesn't need to be
synthesized.
(2) if a signal is not assigned a value, it may be safely tied to a
constant (GND)
While most of the time, these are valid assumptions, this isn't always
the case.
In case (1), if the signal is directed to a hardware pin (using an
OBUF component), the signal is visible from the outside world, which
must count as a side effect - implying the net must be syntesized.
In case (2), if the signal is comping from a hardware pin (uning an
IBUF component), the value need not be GND (or even constant).
Having these inferences made anyway leads to all kinds of warnings,
errors (e.g. "Multiple Drivers" errors in the second case), and in
general an inability to synthesize what are (should be) completely
valid models.
Any help would be greatly appreciated.
Best regards,
Sidney Cadot
The Netherlands
Article: 75231I had developed some code for xc9572 in webpack but have some problems with testing and simulation. How could i define input signal with phase modulation (with jitter) for multisim testing?? Have no idea Greetings 5hinkaArticle: 75232
Hi, >>For X board (NON working..) >>| clk_ret_i | BUFGMUX0S| No | 2172 | 0.272 | 1.188 >>| cclk_in_aux | BUFGMUX4S| No | 33 | 0.069 | 1.157 >>| cclk_in_g | BUFGMUX3S| No | 3 | 0.000 | 1.136 >>| dclk_g | BUFGMUX6S| No | 10 | 0.007 | 1.150 >>For Y board (working..) >>| clk_ret_i | BUFGMUX2S| No | 2171 | 0.272 | 1.188 >>| cclk_in_aux | BUFGMUX4S| No | 33 | 0.029 | 1.167 >>| cclk_in_g | BUFGMUX7P| No | 5 | 0.138 | 1.161 >>| dclk_g | BUFGMUX6S| No | 10 | 0.005 | 1.111 > Given the above BUFGMUX locations, I think Board X should be working > and Y should have bad clocks. > Board Y BUFGMUXs for cclk_in_g and dclk_g are using adjacent BUFGMUXs > which is not correct. I got confirmation today that the whole system of 24 board (all with the y board clock configuration) has worked and passed the initial testing. Its part of a hep physics experiment so kind of important that it works :) I would have though that given control over clock placing that the place &route tool wouldn't choose a non-working combination ( be that the x or y above...) but then you live and learn.. /\/\arcArticle: 75233
Simon Peacock wrote: > > I think the PSU does see the short spikes... just over a longer period. Context! The point was that async logic spreads the spikes out while sync logic lumps them together. Actually that is not really true except for the IO currents. All the logic elements in a chip switch as the inputs change. With the different delays between FFs there are a lot of individual switching currents. Even sync logic uses async combinatorial logic, but the FFs are slaved to a common clock. Regardless, whether you group all the switching current spikes together or spread them out, the PSU sees them the same way due to their high speed and the slowness of the PSU. These switching currents run much faster than the PSU switches or an LDO could possibly respond! > I don't know if there's more than just PHd Thesis about at the moment. > Philips had something.. but it might be in house and I'm sure there's tons > of stuff if you ask the right person. The stuff I have is getting old to > old really.. but it is still relevant as the field doesn't seem to have > moved very far in the last 8 years. > > When you talk about keeping all the silicon busy.. that's a fairy tail. When > did your last design use every bit of silicon for every clock? I don't > believe they do.. any piece of complex silicon doesn't use itself 100% all > the time. I didn't say 100%. I just said you need to keep it as busy as possible. If an async circuit has five stages with different delays, you have to wait for all five stages to complete before starting a new data flow. Although I guess if you used handshaking between each stage, rather than just a self timed clock, you could then keep each stage busy, but only at the rate of the slowest stage. But doen't that sound familiar? > My own designs work in bursts... I even build a simple FIFO using shift > registers which swap out ever second cycle.. so they're not used all the > time .. even less than 50%. Other parts only use one clock in 8. quite in > efficient really.. but I only have one 16 MHz clock so that's the way it is. > I don't know how much async logic would help for designs like this.. mainly > because the input is sync and the output too.. but that's just one app. Actually, I think FIFOs were among the earliest async logic components. Back in TTL days a FIFO was actually a series of registers with a handshake circuit connecting adjacent registers. If you wrote a word to an empty FIFO you had to wait for the data to ripple through before you could read it at the other end. > "... but an async circuit has to propagate the clock ..." > You are thinking sync again.. Async circuits don't have a clock.. so nothing > to propagate they rely on hand shakes, delays and just in time. > Clocks are forbidden except in cross over designs (that the sync designer > hasn't got his head around yet!) Yes, both async and sync sequential circuits have a clock. In async the clock just passes between adjacent stages. You are calling it a handshake, but this is used as a clock on FFs somewhere. Else how do you trigger the FFs? > There are tricks to aligning parallel paths.. known by sorcerers and > magicians everywhere but not witch doctors. > > And yes.. chip users do pay for power and silicon. But as long as they > pay, the suppliers don't complain. so they decide what's best for them.. > and more chips per wafer is a big plus on the balance sheet. Of course this > rule doesn't so much apply to Intel. but they have a bonus of windows.. > where you can never have too much power. Hmmmm... well this could go on all day. I still stand by my point that most of the claims of how async circuits are better don't hold water. They may be different, but not necessarily better. I'm not sure anyone has given a single way in which async circuits are *clearly* better. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75234
Simon Peacock wrote: > I just thought of one way async circuits are a PITA for the board designer to use. Sync circuits are typically designed to run correctly over temp. The chip builder provides a spec for temperature. Then your circuit speed is set by the clock. An async circuit is designed to work over a temp range, but is self timed. So the board designer has to test over temperature to make sure the circuit speed will be fast enough. I was just looking at the data sheet for the P87CL888 and realized that it would be very hard to verify the speed of the software vs. your system requirements. The board designer would have to verify the system at worst case temperature, voltage *and* process... again, the self timed clocking is not an advantge when your system requirements have to be met at the slowest speed. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75235
> I thought the original poster was looking for 3.3V or 5.0V. Max II is 3.3V > tolerant, not 5.0V tolerant. A quick follow-up -- you can drive and listen to 5.0V-compatible signals with Max II. You can directly drive a 5.0V TTL device using all Max II devices since the Voh of the 3.3V output is above the 2.4V requirement of the TTL device. To drive a 5.0V CMOS device, you need to enable the PCI clamping diode and use an external pull-up resistor. To listen to a 5.0V signal, you again enable the PCI clamp diode and add a series resistor to the connection. PCI clamping diodes are available on the two largest family members. Details can be found at http://www.altera.com/literature/hb/max2/max2_mii51009.pdf. Regards, Paul Leventis Altera Corp.Article: 75236
Hi Andre, > is it possible to feed the input of a second PLL (Cyclone EP1C12) > with an output clock (for example c0) of the first PLL ? In Cyclone and Cyclone II, the PLL inputs can only be driving by dedicated clock pins. The PLL does provide an external output, so I guess you could route that to the other PLL input on your board. Regards, Paul Leventis Altera Corp.Article: 75237
Sidney Cadot wrote: > > Hi all, > > The following VHDL code does not synthesize using XST 6.2.03: > > ----- start of fragment > > -- The challenge is to define an entity that replicates > -- an input port (push button) to an output port (LED), > -- without declaring them in the entity's ports. > > library ieee, unisim; > > use ieee.std_logic_1164.all, unisim.vcomponents.all; > > entity toplevel is > -- wire input button to output LED > -- without using a port declaration > end entity toplevel; > > architecture arch of toplevel is > > signal BUTTON : std_logic; > signal LED : std_logic; > signal sig_led : std_logic; > signal sig_button : std_logic; > > attribute LOC : string; > > attribute LOC of BUTTON : signal is "P22"; > attribute LOC of LED : signal is "P20"; > > component OBUF is > port (O: out std_ulogic; I: in std_ulogic); > end component OBUF; > > component IBUF is > port (O: out std_ulogic; I: in std_ulogic); > end component IBUF; > > begin > > button_buf : component IBUF port map(O => sig_button , I => BUTTON); > led_buf : component OBUF port map(O => LED , I => not > sig_led); > > sig_led <= sig_button; > > end architecture arch; > > ----- end of fragment > > The following problem seems to be causing this. When a signal is used > that does not correspond to a top-level in/out port, it seems that XST > makes the following inferences: > > (1) if a signal does not drive anything, it doesn't need to be > synthesized. > (2) if a signal is not assigned a value, it may be safely tied to a > constant (GND) > > While most of the time, these are valid assumptions, this isn't always > the case. > > In case (1), if the signal is directed to a hardware pin (using an > OBUF component), the signal is visible from the outside world, which > must count as a side effect - implying the net must be syntesized. > > In case (2), if the signal is comping from a hardware pin (uning an > IBUF component), the value need not be GND (or even constant). But you must actually connect it to an outside pin. All you have done is name the net on the other side of the IBUF or OBUF, you have not connected it to the outside world. That is what the port definition is for. Look at it from the perspective of the VHDL compiler. Your signal button has no driver specifed for it. You are expecting the compiler to figure out that an IBUF connects to the outside world. You have to tell it that by using a port definition. > Having these inferences made anyway leads to all kinds of warnings, > errors (e.g. "Multiple Drivers" errors in the second case), and in > general an inability to synthesize what are (should be) completely > valid models. > > Any help would be greatly appreciated. > > Best regards, > Sidney Cadot > The Netherlands -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75238
"Paul Leventis (at home)" wrote: > > > I thought the original poster was looking for 3.3V or 5.0V. Max II is > 3.3V > > tolerant, not 5.0V tolerant. > > A quick follow-up -- you can drive and listen to 5.0V-compatible signals > with Max II. You can directly drive a 5.0V TTL device using all Max II > devices since the Voh of the 3.3V output is above the 2.4V requirement of > the TTL device. > > To drive a 5.0V CMOS device, you need to enable the PCI clamping diode and > use an external pull-up resistor. To listen to a 5.0V signal, you again > enable the PCI clamp diode and add a series resistor to the connection. PCI > clamping diodes are available on the two largest family members. > > Details can be found at > http://www.altera.com/literature/hb/max2/max2_mii51009.pdf. What if the 5 volt signal is bidir TTL? Doesn't the input resistor get in the way of driving the net? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75239
On Sat, 30 Oct 2004 12:16:40 -0400, rickman wrote: > > Yes, both async and sync sequential circuits have a clock. In async the > clock just passes between adjacent stages. You are calling it a > handshake, but this is used as a clock on FFs somewhere. Else how do > you trigger the FFs? > The word clock implies a global clock, or at least a clock that goes to every flip-flop (storage element) in a large section of the chip. The handshake signals in async design are local, rather than global in nature (with, among other things, the benefit of greatly reduced EMI). > > Hmmmm... well this could go on all day. I still stand by my point that > most of the claims of how async circuits are better don't hold water. > They may be different, but not necessarily better. I'm not sure anyone > has given a single way in which async circuits are *clearly* better. Take a look at the book "Asynchronous Circuit Design" written by Chris J. Meyers and published by Wiley in 2001. Chapter 9 gives some examples that clearly contradict your comments. One example (RAPPID at Intel) give a simultaneous 3:1 improvement in speed, a 50% improvement in power, and a much larger input voltage range over the synchronous design using the same fab process, at the expense of 22% more chip area. Other examples showed similar results. -- PhilArticle: 75240
>An async circuit is designed to work over a temp range, but is self >timed. So the board designer has to test over temperature to make sure >the circuit speed will be fast enough. .. I'm missing something. Why test the board as compared to read the worst case numbers off the data sheet and see if they are fast enough? It's the same problems as checking setup/hold times. Just turned inside out. Is the info not in the data sheet? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75241
>Take a look at the book "Asynchronous Circuit Design" written by Chris J. >Meyers and published by Wiley in 2001. Chapter 9 gives some examples that >clearly contradict your comments. One example (RAPPID at Intel) give a >simultaneous 3:1 improvement in speed, a 50% improvement in power, and a >much larger input voltage range over the synchronous design using the same >fab process, at the expense of 22% more chip area. Other examples showed >similar results. So why hasn't async technology grabbed a bigger chunk of the market? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75242
On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote: >>Take a look at the book "Asynchronous Circuit Design" written by Chris J. >>Meyers and published by Wiley in 2001. Chapter 9 gives some examples that >>clearly contradict your comments. One example (RAPPID at Intel) give a >>simultaneous 3:1 improvement in speed, a 50% improvement in power, and a >>much larger input voltage range over the synchronous design using the same >>fab process, at the expense of 22% more chip area. Other examples showed >>similar results. > > So why hasn't async technology grabbed a bigger chunk of the market? I would assume that async technology is being held back, in part, because of the lack of widespread availability of design tools, designers familiar with the techniques involved, and of good production test and characterization tools, and so forth. A chicken and egg situation is how I would put it. -- PhilArticle: 75243
Phil Short wrote: > On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote: > > >>>Take a look at the book "Asynchronous Circuit Design" written by Chris J. >>>Meyers and published by Wiley in 2001. Chapter 9 gives some examples that >>>clearly contradict your comments. One example (RAPPID at Intel) give a >>>simultaneous 3:1 improvement in speed, a 50% improvement in power, and a >>>much larger input voltage range over the synchronous design using the same >>>fab process, at the expense of 22% more chip area. Other examples showed >>>similar results. >> >>So why hasn't async technology grabbed a bigger chunk of the market? > > > I would assume that async technology is being held back, in part, because > of the lack of widespread availability of design tools, designers familiar > with the techniques involved, and of good production test and > characterization tools, and so forth. A chicken and egg situation is how > I would put it. A good summary, and it also has to do with 'path of least resistance' - it was easier/cheaper to simply shrink to gain speed. That is starting to no longer be true, and at the same time ASYNC tools are getting better [hence the Philips/ARM announcement, which is really a Tool Chain one]. -jgArticle: 75244
In the Altera nios reference design in the cyclone kit,the sdram pll clock phase shift is -3.5ns. "This PLL introduces a phase-shift which compensates for board-level delays in the clock network.Other boards my require different settings." I don't know how to calculate the delays on my board. Could someone tell me the way to calculate the board-level delays? Thanks and RegardsArticle: 75245
In article <cm1iol$2c7o$1@mail.cn99.com>, kingkang <305liuzg@163.net> wrote: >I don't know how to calculate the delays on my board. >Could someone tell me the way to calculate the board-level delays? Some DDR designs require a loop on the board equal to the average bus trace length and then use that to "measure" it. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 75246
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:6sVgd.24109$mZ2.911799@news02.tsnz.net... > Phil Short wrote: > > On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote: > > > > > >>>Take a look at the book "Asynchronous Circuit Design" written by Chris J. > >>>Meyers and published by Wiley in 2001. Chapter 9 gives some examples that > >>>clearly contradict your comments. One example (RAPPID at Intel) give a > >>>simultaneous 3:1 improvement in speed, a 50% improvement in power, and a > >>>much larger input voltage range over the synchronous design using the same > >>>fab process, at the expense of 22% more chip area. Other examples showed > >>>similar results. > >> > >>So why hasn't async technology grabbed a bigger chunk of the market? > > > > > > I would assume that async technology is being held back, in part, because > > of the lack of widespread availability of design tools, designers familiar > > with the techniques involved, and of good production test and > > characterization tools, and so forth. A chicken and egg situation is how > > I would put it. > > A good summary, and it also has to do with 'path of least resistance' > - it was easier/cheaper to simply shrink to gain speed. > That is starting to no longer be true, and at the same time ASYNC > tools are getting better [hence the Philips/ARM announcement, which is > really > a Tool Chain one]. > I believe this is the perfect answer to the problem.. why ?? because no one demands it! If enough people wanted, and more important, laid cash out .. Xilinx would build a self timed, fully async FPGA. But I pity the support staff, and of course Mentor and Symplicity tools get thrown out... for another set of course. so there's another $50k to spend, and the extra pity for their support staff.. So reality is.. its probably too expensive to change, until the current sync technology has reached its limit, the tools and design know how is already paid for. Of course there can always be another Microsoft.. who comes up with the perfect 'toy' that everyone wants (and think they need) that uses async technology and completely flips the industry over in a matter of years. :-) From that point.. its most likely to be an ultra fast, ultra big, ultra low power 'something' for computers or a play station. Maybe a graphics chip that draws almost no power and does a billion polygon's a millisecond. SimonArticle: 75247
Come on folks.. I need some help with Xilinx Platform Studio..Article: 75248
jm_contact2002@yahoo.fr (jerome) wrote in message news:<96a74216.0410280152.436c4fc3@posting.google.com>... > Hello, > > Could someone give me information about the Nuhorizon Spartan-3 > Development Board? > It seems to be a good one based upon the Spartan-3 400 thousand gate > FPGA (XC3S400-4PQ208C). > Could someone confirme me I can use it with the ISE Webpack 6? > A contact in NuHorizon told me I need full software, but I don't > understand. > > Any other comment or suggestion? > > Thanks, > > Jerome. We have had an extremely negative experience dealing with Nu Horizons. They "take" orders, then don't deliver. After very persistent calling they deliver partials, some of which are defective. Don't deal with them-they are VERY UNRELIABLE!!!Article: 75249
hai naren...unfortunately I cannot help you..but I've had a similar problem....I had to give up..Let me know if u come to know..thanx
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