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
etrac wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F93E4A8.C68E3142@yahoo.com>... > > Isn't that a common mode during power on? Exactly what problem does > > this cause? Are you saying that the current causes a voltage foldback > > so that the rise is not monotonic? If so, your problem is not the > > capacitors, it is the foldback current limiting. I find it hard to > > imagine the caps on a board having more total capacitance than a power > > supply. But I guess you may be working with an on board DC/DC with 100 > > uF or less. > > > > -- > > > > Rick "rickman" Collins > > We use Motorola QuiccSupply products to power the FPGA, they have two > protections : overcurrent protection and undervoltage lockout. The > first limits the current, the second disables the power if the voltage > is not in the good range (checked every 100ms). That's why if C is big > the power supply can't raise the voltage quickly and the QuiccSupply > goes in undervoltage lockout. > > That's true that if the Power supply doesn't have any undervoltage > lockout capability we did not have such problems .. Nevertheless > Virtex II documentation says that at power on, each supply line (VCCO > VCCAUX and VCCINT) has to be stable quickly (< 200 ms if I remember > well), otherwise the component will need more current to power on. > So I think that having too many bypassing capacitors may affect the > power on. Of course this event depends on the power supply used .. > > Etrac But if you do the math with the magnitude of current, voltage and times you will find that it requires an *enormous* amount of capacitance to obstruct your ramp time. Using 5 volts, 2 Amps and 50 mS, I get 20,000 uF. Clearly anything in a typical range of capacitance (~100-200 uF) should not adversely impact your power on ramp unless all the supply current is going through the chips. Are the chips drawing enough current at power up that the supply is nearly current limited? -- 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: 63177
This Digilent combo package looks to me like an excellent way to learn FPGAs (but then, I don't know anything yet!): http://www.digilentinc.com/Catalog/digilab_2_dio2.html Do more experienced eyes see any gotchas with this setup? I realize the FPGA is bigger than a beginner needs, but the price seems good, and I gather the part is from a mainstream FPGA family. Thanks.Article: 63178
petersommerfeld@hotmail.com (Peter Sommerfeld) wrote in message news:<5c4d983.0311170541.5bd0c1db@posting.google.com>... > What does this generic means? > > I am wondering if I am missing out on a possible memory optimization. > > Altera's docs are decidedly vague and a search on their website brings up nothing. > > -- Pete MAXIMUM_DEPTH controls the underlying RAM block size that will be used to construct the user's altsyncram memory. By default, the altsyncram megafunction will round up the memory depth to the next power-of-2, and use that as a RAM block size. For example, if you ask for a 3K-word memory, altsyncram will normally construct it from 4K RAM blocks, because this gives the best performance. If you are running short of RAM blocks, you could specify MAXIMUM_DEPTH=1024 for this example, and the altsyncram megafunction will construct the 3K memory from 1K-word RAM blocks, which might potentially use 1/4 fewer RAM blocks. The penalty for doing this is that the 3K-word memory constructed from 1K-word RAM blocks will need LEs to mux and de-mux the data, and will also run slower as a result. In summary, MAXIMUM_DEPTH is a control to increase memory efficiency for non-power-of-2 memory depths, but at a cost of lower memory performance, and a few LEs to stitch the smaller RAM blocks together. MAXIMUM_DEPTH can only take power-of-2 values, with 32 being the smallest meaningful value, since it corresponds to the shallowest M512 memory block configuration. - Subroto Datta Altera Corp.Article: 63179
I've been playing with a test design consisting of a single 16x16=32 coregen generated multiplier with maximum pipelining and the registered output option. I am using ISE5.2 and I set the clk constraint to 200 MHz (and it is the only constraint). The results I am getting for different speed grades of the same XC2V2000 device are as follows: 6 - 4.986 ns 5 - 4.910 ns 4 - 5.839 ns It seems a little weird that the middle grade is faster... Any comments on that? Also, is this pretty much the best I can get? I might need to do a design that will have to run at 210 MHz and I don't feel comfortable with these results. I know this topic has been discussed in the past but I could not find good conclusive numbers... Thanks, /MikhailArticle: 63180
Hi all, I am targeting my design on Acex EP1K100QC208-3 FPGA. I did most of my development using Leonardo Spectrum synthesizer(2002) and Max +2. My license for leonardo expired, and I decided to use Quartus II(v3.0). When I compile using Quartus, Iam getting a negative slack time for one of my clock. when I compiled the same FPGA code using LS and Max +2, I did not have any timing issues . In the compiler settings, I have enabled the "optimize i/o cell register placement for timing" option. I also tried different synthesis tool in quartus (FPGA express, LS,..) but I could not get the timing right. Can anyone help me? Thanks, KumaranArticle: 63182
Looks good to me. I am actually not sure if this level of complexity (number of peripherals) is required for learning, perhaps you could find something cheaper with less peripherals. With this kit you could design a small microprocessor, but you would probaly have to add some external memory (through the provided expansion ports) to make any practical use of it... /Mikhail "Mike Silva" <snarflemike@yahoo.com> wrote in message news:20619edc.0311171148.4b9d44f5@posting.google.com... > This Digilent combo package looks to me like an excellent way to learn > FPGAs (but then, I don't know anything yet!): > > http://www.digilentinc.com/Catalog/digilab_2_dio2.html > > Do more experienced eyes see any gotchas with this setup? I realize > the FPGA is bigger than a beginner needs, but the price seems good, > and I gather the part is from a mainstream FPGA family. > > Thanks.Article: 63183
On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea <Austin.Lesea@xilinx.com> wrote in <3FB8EB97.5DA6720F@xilinx.com>: >Jan, > >Yes, they are all internally connected on the die (once the IOB is programmed >as a Vref). That explains why I measure OC with an Ohm meter. >Since these are also general purpose IOBs, there is no bypass cap in the >package, nor on the internal Vref line, so all external Vref pins must be >externally individually bypassed to ground with bypass caps as close as >possible to the Vref pins AND connected to the Vref supply to get the lowest >noise Vref possible. hehe, I am using Vref as video input, trying to use the thing as AD. On the other input of the comparator is an r2r ladder. The verilog does successive approximation. I ran into problems because indeed now Vref is 75 Ohm impedance to ground, and this pin is very sensitive. Connecting all Vrefs makes little difference. But I do have video (via second r2r ladder out again), but some spikes are at some places for example if you put in a sine wave. Seems I will have to sample and hold first too... Still some instability in that input comparator, if sh does not fix it I will try using external comparator. Also it works to digitize audio it seems. It is just for play.... Thanx JanArticle: 63184
andres.vazquez@gmx.de (Vazquez) wrote in message news:<eee19a7a.0311170507.4495f94d@posting.google.com>... > Dear Sir or Madame, > > I have the following problem: > > In a clocked process I made the following registered signal > assignments: > > ------------------------------------------------------------ > ------------------------------------------------------------ > entity xy is > port( addr_to_send : in std_logic_vector(6 downto 0); > ep_to_send : in std_logic_vector(3 downto 0); > addr_rec : in std_logic_vector(6 downto 0); > ep_rec : in std_logic_vector(3 downto 0); > direction_to_send : in std_logic; > cam_ram_entry_valid : in std_logic; > ... > ); > end xy; > > architecture ... > > process(write_clock) > begin > if rising_edge(write_clock) then > > l_data_addr_to_send <= ( addr_to_send(6 downto 0) & ep_to_send(2 > downto 0) ); > > l_data_addr_rec <= ( addr_rec(6 downto 0) & ep_rec(2 downto > 0) ); > > l_data_to_send <= ( addr_to_send(6 downto 0) & ep_to_send(3 > downto 0) & direction_to_send & cam_ram_entry_valid); > > end if; > end process; > > -------------------------------------------------------------- > -------------------------------------------------------------- > > When I open the NodeFinder in the AlteraQuartusII software (after > Synthesis)I > see that > - l_data_addr_to_send are registered nodes : OK > > - only l_data_rec[0], l_data_rec[4] are registered nodes > the other bits of l_data_rec are not shown at all ??? > > - only l_data_to_send[0], l_data_to_send[1], l_data_to_send[5] are > registered nodes > the other bits of l_data_to_send are not shown at all ??? > > So my question: Why did the synthesis tool not recognize all bits > to be registered ? > > Thank you very much. > > Kind regards > > Andrés Vázquez Hi Andrés, The Quartus software is merging duplicate registers in the code without altering the functionality of your design. Specifically, l_data_addr_to_send and l_data_to_send are driven by many of the same inputs; hence, it shares the registers implementing these signals. If you want to keep all register bits, even duplicates, then 1.Use the Preserve Attribute on the registered signals, OR 2. Turn "Remove Duplicate Registers" off in the Assignments->Settings->Default Logic Option Settings. - Subroto Datta Altera CorpArticle: 63185
Mikhail,
The reason that the -5 part appears to be faster is that the PAR tool
stops optimising when the timing passes. You set it to 5ns. Once it got
better than this it stopped bothering to improve further. It just so
happened that the PAR with the -5 part did a tiny bit better.
It might sound radical, but if you want it to work at 210MHz, try doing
the PAR with the constraint to 210MHz! ;-) See what happens and report back!
cheers, Syms.
"MM" <mbmsv@yahoo.com> wrote in message
news:bpba7l$1ljnjm$1@ID-204311.news.uni-berlin.de...
> I've been playing with a test design consisting of a single 16x16=32
coregen
> generated multiplier with maximum pipelining and the registered output
> option. I am using ISE5.2 and I set the clk constraint to 200 MHz (and it
is
> the only constraint). The results I am getting for different speed grades
of
> the same XC2V2000 device are as follows:
>
> 6 - 4.986 ns
> 5 - 4.910 ns
> 4 - 5.839 ns
>
> It seems a little weird that the middle grade is faster... Any comments on
> that?
>
> Also, is this pretty much the best I can get? I might need to do a design
> that will have to run at 210 MHz and I don't feel comfortable with these
> results. I know this topic has been discussed in the past but I could not
> find good conclusive numbers...
>
>
> Thanks,
> /Mikhail
>
>
>
Article: 63186This is a multi-part message in MIME format. --------------D156AFDDD09D7551D00DAC0B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mikhail, I assume your talking about par results, once the implementation tools achieve your constraints they stop. A better way to view the results is 6- constraint = 5.0ns PASS 5- constraint = 5.0ns PASS 4- constraint = 5.0ns FAIL If you want to run the implementation at 210MHz I suggest you benchmark at 210MHz, or slightly faster if you are trying to gauge some margin. MM wrote: > I've been playing with a test design consisting of a single 16x16=32 coregen > generated multiplier with maximum pipelining and the registered output > option. I am using ISE5.2 and I set the clk constraint to 200 MHz (and it is > the only constraint). The results I am getting for different speed grades of > the same XC2V2000 device are as follows: > > 6 - 4.986 ns > 5 - 4.910 ns > 4 - 5.839 ns > > It seems a little weird that the middle grade is faster... Any comments on > that? > > Also, is this pretty much the best I can get? I might need to do a design > that will have to run at 210 MHz and I don't feel comfortable with these > results. I know this topic has been discussed in the past but I could not > find good conclusive numbers... > > Thanks, > /MikhailArticle: 63187
"Symon" <symon_brewer@hotmail.com> wrote in message news:bpauqv$1n8qij$1@ID-212844.news.uni-berlin.de... > Hi Ken, > One way to find out is to wade through the EDIF file and see what > Synplify has made. I suspect you'll find that the fault lies with the > map/par stages though. This happened to me when one of my designs started to > fill up the part, i.e. Slice % went to 100%, LUT % was maybe 70%. There were > a lot of long carry chains in it, and the Xilinx tools would break the > chains to make it fit. Floorplanning fixed the problem, I didn't try using > RLOC (see constraints guide) to fix the relative placement of the chain > elements, although this should work too. > Good luck mate, Syms. Symon, Thanks for the reply. I will take a look through the edif as you suggest. However, the design is about 700 slices of a 14000 odd slice part so it is not a utilisation issue.... Cheers, Ken --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.541 / Virus Database: 335 - Release Date: 14/11/2003Article: 63188
"Alan Fitch" <alan.fitch@doulos.com> writes: > "Jay" <yuhaiwen@hotmail.com> wrote in message > news:bpa4cc$1lsdcn$1@ID-195883.news.uni-berlin.de... > > I've installed sp3, but still can't work. > > > > error info: > > ld.so.1: promgen: fatal: libBs_Bitstream.so: open failed: No such > file or > > directory > > > > and the file is there: > > ls -l /SW/xilinx/bin/sol/libBs_Bitstream.so > > -r-xr-xr-x 1 xilinx sw 149088 Nov 17 16:52 > > /SW/xilinx/bin/sol/libBs_Bitstream.so > > > > Is it a bug? > > > > > Check that you have > > /SW/xilinx/bin/sol > > in your LD_LIBRARY_PATH variable, This can usually be achieved doing . /SW/xilinx/settings.sh ; in sh compatible shells like bash, or source /SW/xilinx/settings.csh ; in csh compativle shells like tcsh Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 63189
"Symon" <symon_brewer@hotmail.com> wrote in message
news:bpbfmp$1n2qp1$1@ID-212844.news.uni-berlin.de...
> Mikhail,
> It might sound radical, but if you want it to work at 210MHz, try
doing
> the PAR with the constraint to 210MHz! ;-) See what happens and report
back!
OK, here is my report (use fixed size font to see better):
Requested Actual
-6 -5 -4
5 4.986 4.910 5.839
4.65 4.561 5.146 5.839
4.5 4.328 5.146 5.828
4 4.543 5.146 Impossible
4.3 4.543 5.146 Impossible
4.4 4.328 5.140 Impossible
All of this has been done with default implementation settings.
/Mikhail
Article: 63190Jan, If you want to play with the Vref as a video input, you can place an input buffer on each of the other Vref pins, which will give your warnings, but the device will still get a bitstream which now disconnects the Vref bus internally from the other Vref pins (the ones that you used by breaking the rules). Austin Jan Panteltje wrote: > On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea > <Austin.Lesea@xilinx.com> wrote in <3FB8EB97.5DA6720F@xilinx.com>: > > >Jan, > > > >Yes, they are all internally connected on the die (once the IOB is programmed > >as a Vref). > That explains why I measure OC with an Ohm meter. > > >Since these are also general purpose IOBs, there is no bypass cap in the > >package, nor on the internal Vref line, so all external Vref pins must be > >externally individually bypassed to ground with bypass caps as close as > >possible to the Vref pins AND connected to the Vref supply to get the lowest > >noise Vref possible. > hehe, I am using Vref as video input, trying to use the thing as AD. > On the other input of the comparator is an r2r ladder. > The verilog does successive approximation. > I ran into problems because indeed now Vref is 75 Ohm impedance to ground, > and this pin is very sensitive. > Connecting all Vrefs makes little difference. > But I do have video (via second r2r ladder out again), but some spikes are at > some places for example if you put in a sine wave. > Seems I will have to sample and hold first too... > Still some instability in that input comparator, if sh does not fix it I will > try using external comparator. > Also it works to digitize audio it seems. > It is just for play.... > Thanx > JanArticle: 63191
In article <20619edc.0311171148.4b9d44f5@posting.google.com>, Mike Silva <snarflemike@yahoo.com> wrote: >This Digilent combo package looks to me like an excellent way to learn >FPGAs (but then, I don't know anything yet!): > >http://www.digilentinc.com/Catalog/digilab_2_dio2.html > >Do more experienced eyes see any gotchas with this setup? No external RAM is the biggie; I'd much rather have RAM and USB than fifteen push-button switches and a 2x40 LCD display. TomArticle: 63192
"MM" <mbmsv@yahoo.com> wrote in message
news:bpbiri$1mgke5$1@ID-204311.news.uni-berlin.de...
> "Symon" <symon_brewer@hotmail.com> wrote in message
> news:bpbfmp$1n2qp1$1@ID-212844.news.uni-berlin.de...
> > Mikhail,
> > It might sound radical, but if you want it to work at 210MHz, try
> doing
> > the PAR with the constraint to 210MHz! ;-) See what happens and report
> back!
>
> OK, here is my report (use fixed size font to see better):
>
> Requested Actual
> -6 -5 -4
> 5 4.986 4.910 5.839
> 4.65 4.561 5.146 5.839
> 4.5 4.328 5.146 5.828
> 4 4.543 5.146 Impossible
> 4.3 4.543 5.146 Impossible
> 4.4 4.328 5.140 Impossible
>
> All of this has been done with default implementation settings.
>
> /Mikhail
>
Hi Mikhail,
So, looks like you max out at 230MHz with the -6 parts. If you set the
constraint below 5ns the PAR tool gives up on the -5 part, so looks like
4.91 is the best you'll get with -5. Note, if you over constrain, you don't
get the best results! Other options you could consider would be to use the
built in hardware multipliers alternately, i.e. use two multipliers, so that
each one is active every other go. Use the pipelined versions though.
all the best, Syms.
Article: 63193Jan Panteltje wrote: > > On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea > <Austin.Lesea@xilinx.com> wrote in <3FB8EB97.5DA6720F@xilinx.com>: > > >Jan, > > > >Yes, they are all internally connected on the die (once the IOB is programmed > >as a Vref). > That explains why I measure OC with an Ohm meter. > > >Since these are also general purpose IOBs, there is no bypass cap in the > >package, nor on the internal Vref line, so all external Vref pins must be > >externally individually bypassed to ground with bypass caps as close as > >possible to the Vref pins AND connected to the Vref supply to get the lowest > >noise Vref possible. > hehe, I am using Vref as video input, trying to use the thing as AD. > On the other input of the comparator is an r2r ladder. > The verilog does successive approximation. > I ran into problems because indeed now Vref is 75 Ohm impedance to ground, > and this pin is very sensitive. > Connecting all Vrefs makes little difference. > But I do have video (via second r2r ladder out again), but some spikes are at > some places for example if you put in a sine wave. > Seems I will have to sample and hold first too... > Still some instability in that input comparator, if sh does not fix it I will > try using external comparator. > Also it works to digitize audio it seems. > It is just for play.... You could also try a Tracking ADC, rather than SAR - SAR is sensitive to noise, and have 'noise gain' which means large OP impulse errors can come from small IP errors. (which is what you are seeing) Tracking ADCs are better behaved, and would suit the faster speed / but not analog-optimised resource in the FPGA. - jgArticle: 63194
On Mon, 17 Nov 2003 14:26:39 GMT, "Stratus Engineer" <mjd03003@yahoo.com> wrote: >Would you mind me asking why considering Aldec? I'm looking for a simulation tool that (1) works and (2) handles the current version of Verilog (& pref. VHDL as well) and (3) doesn't have a size limit (or crippled simulation speed) and (4) doesn't cost too much. There's not as much choice as I had first hoped. I'm currently using Icarus (which fails on points 1 and 2). I've considered various versions of Modelsim (which fail on either point 3 or point 4). I've considered Riviera (which fails on point 4). Aldec seems like a logical next step. Any other suggestions? Regards, Allan.Article: 63195
You might find a comment elsewhere in your timing report that fmax is limited by the SRL minimum pulse widths, Twph + Twpl. The 150E-7 timing I had up on my screen (SpeedPrint, v6.1i timing) shows Twph of 2100 ps; Twpl isn't specified in the SpeedPrint output but I recall it's the same as Twph resulting in an SRL-limited fmax of 238 MHz with no jitter and 50.00% duty cycle. You might be able to get XST to avoid inferring s1 as part of the SRL by specifying to XST that it's an IOB register, allowing s2 and Q to be an SRL if XST so chooses. If Q was to be your "stable" value and s1 and s2 were metastability registers, why not use s2 as the stable, synchronized value? I thought only two registers were needed for proper metastability protection, the output of s1 being a "maybe" that settles to a high or low by the time s2 grabs the value. "Hans-Juergen Dorn" <hjdorn@freenet.de> wrote in message news:v1oirvs09jf6jaco5c7pt0luvoel60it5i@4ax.com... > On Mon, 17 Nov 2003 10:11:24 -0800, Peter Alfke <peter@xilinx.com> > wrote: > > >I concur. The SRL16 structure is different from a conventional > >flip-flop. Although it is only the Master latch in a flip-flop that is > >reponsible for metastability (the Slave just does the read-out), this > >might imply that there is no difference. But I still would be leary to > >venture into untested territory. > > > >> Hi Hans-Juergen, > >> Try a search on Google groups "metastability srl". Top answer is a > >> discussion we had here called "Should I worry about metastability". Xilinx's > >> expert, Peter Alfke, said :- > >> > >> I will not guarantee that SRL16s recover as fast from metastability as > >> the "normal" flip-flops that I documented, since SRLs are implemented in > >> a different circuit design. (Different might mean better or worse). > > Mike Tresseler wrote > >> Is there any difference w.r.t metastability in using SRLs > >> compared to FDs? > > >Don't know. Check the data sheet. > > >Or check fmax, with and without a reset. > > Hey, thank you all for answering! > > The fmax of a single SRL seems to be way beyond the > capacity of the global clock nets. (At least for Spartan2E, that is) > > If I do something like - > > p : process(clk) is > signal s1, s2 : std_logic; > begin > if clk'event and clk='1' then > s1 <= A; > s2 <= s1; > Q <= s2; > end if > end process; > > - I'll get an Fmax of 561Mhz on a XC2S50e-7 !!! > At least WP4.2's timing analyzer seems to think so... > > But anyway, I guess I'll stick to throwing FDE's at all that > nasty stuff coming from the outside... > > Regards Hans > > P.S: > > If you think, you found an easy way of doing something in VHDL, > you're probably doing it wrong. :o) >Article: 63196
One way to assure that XST will use regular FFs, not SRLs, is to supply a Reset signal. SRLs do not have reset, so XST will avoid them. "John_H" <johnhandwork@mail.com> wrote: :You might find a comment elsewhere in your timing report that fmax is :limited by the SRL minimum pulse widths, Twph + Twpl. The 150E-7 timing I :had up on my screen (SpeedPrint, v6.1i timing) shows Twph of 2100 ps; Twpl :isn't specified in the SpeedPrint output but I recall it's the same as Twph :resulting in an SRL-limited fmax of 238 MHz with no jitter and 50.00% duty :cycle. : :You might be able to get XST to avoid inferring s1 as part of the SRL by :specifying to XST that it's an IOB register, allowing s2 and Q to be an SRL :if XST so chooses. : :If Q was to be your "stable" value and s1 and s2 were metastability :registers, why not use s2 as the stable, synchronized value? I thought only :two registers were needed for proper metastability protection, the output of :s1 being a "maybe" that settles to a high or low by the time s2 grabs the :value. : : :"Hans-Juergen Dorn" <hjdorn@freenet.de> wrote in message :news:v1oirvs09jf6jaco5c7pt0luvoel60it5i@4ax.com... :> On Mon, 17 Nov 2003 10:11:24 -0800, Peter Alfke <peter@xilinx.com> :> wrote: :> :> >I concur. The SRL16 structure is different from a conventional :> >flip-flop. Although it is only the Master latch in a flip-flop that is :> >reponsible for metastability (the Slave just does the read-out), this :> >might imply that there is no difference. But I still would be leary to :> >venture into untested territory. :> :> :> >> Hi Hans-Juergen, :> >> Try a search on Google groups "metastability srl". Top answer is a :> >> discussion we had here called "Should I worry about metastability". :Xilinx's :> >> expert, Peter Alfke, said :- :> >> :> >> I will not guarantee that SRL16s recover as fast from metastability as :> >> the "normal" flip-flops that I documented, since SRLs are implemented :in :> >> a different circuit design. (Different might mean better or worse). :> :> Mike Tresseler wrote :> >> Is there any difference w.r.t metastability in using SRLs :> >> compared to FDs? :> :> >Don't know. Check the data sheet. :> :> >Or check fmax, with and without a reset. :> :> Hey, thank you all for answering! :> :> The fmax of a single SRL seems to be way beyond the :> capacity of the global clock nets. (At least for Spartan2E, that is) :> :> If I do something like - :> :> p : process(clk) is :> signal s1, s2 : std_logic; :> begin :> if clk'event and clk='1' then :> s1 <= A; :> s2 <= s1; :> Q <= s2; :> end if :> end process; :> :> - I'll get an Fmax of 561Mhz on a XC2S50e-7 !!! :> At least WP4.2's timing analyzer seems to think so... :> :> But anyway, I guess I'll stick to throwing FDE's at all that :> nasty stuff coming from the outside... :> :> Regards Hans :> :> P.S: :> :> If you think, you found an easy way of doing something in VHDL, :> you're probably doing it wrong. :o) :> :Article: 63197
On Mon, 17 Nov 2003 10:11:24 -0800, Peter Alfke <peter@xilinx.com>
wrote:
>I concur. The SRL16 structure is different from a conventional
>flip-flop. Although it is only the Master latch in a flip-flop that is
>reponsible for metastability (the Slave just does the read-out), this
>might imply that there is no difference. But I still would be leary to
>venture into untested territory.
>> Hi Hans-Juergen,
>> Try a search on Google groups "metastability srl". Top answer is a
>> discussion we had here called "Should I worry about metastability". Xilinx's
>> expert, Peter Alfke, said :-
>>
>> I will not guarantee that SRL16s recover as fast from metastability as
>> the "normal" flip-flops that I documented, since SRLs are implemented in
>> a different circuit design. (Different might mean better or worse).
Mike Tresseler wrote
>> Is there any difference w.r.t metastability in using SRLs
>> compared to FDs?
>Don't know. Check the data sheet.
>Or check fmax, with and without a reset.
Hey, thank you all for answering!
The fmax of a single SRL seems to be way beyond the
capacity of the global clock nets. (At least for Spartan2E, that is)
If I do something like -
p : process(clk) is
signal s1, s2 : std_logic;
begin
if clk'event and clk='1' then
s1 <= A;
s2 <= s1;
Q <= s2;
end if
end process;
- I'll get an Fmax of 561Mhz on a XC2S50e-7 !!!
At least WP4.2's timing analyzer seems to think so...
But anyway, I guess I'll stick to throwing FDE's at all that
nasty stuff coming from the outside...
Regards Hans
P.S:
If you think, you found an easy way of doing something in VHDL,
you're probably doing it wrong. :o)
Article: 63198Allan Herriman wrote: > > On Mon, 17 Nov 2003 14:26:39 GMT, "Stratus Engineer" > <mjd03003@yahoo.com> wrote: > > >Would you mind me asking why considering Aldec? > > I'm looking for a simulation tool that (1) works and (2) handles the > current version of Verilog (& pref. VHDL as well) and (3) doesn't have > a size limit (or crippled simulation speed) and (4) doesn't cost too > much. > > There's not as much choice as I had first hoped. > > I'm currently using Icarus (which fails on points 1 and 2). > I've considered various versions of Modelsim (which fail on either > point 3 or point 4). > I've considered Riviera (which fails on point 4). > > Aldec seems like a logical next step. Any other suggestions? > > Regards, > Allan. I have used ModelSim in a couple of jobs as well as part of the low cost or free tools that X and A offer(ed). I contacted Aldec about their simulator since I expected it to be much cheaper. Sadly, it is not and in fact is a bit more expensive. So if ModelSim fails on point 4, then Aldec will too (along with most of the others). On the other hand, many of the simulations I do run just fine with the speed crippling, so I am ok for the moment. Have you looked at any of the open source tools? Is that what Icarus is? I am not familiar with them, but I know they exist. -- 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: 63199
Hi Dan,
Have you considered that this is maybe the opportunity you've been
waiting for to change to a HDL?!
cheers, Symon.
"Dan DeConinck" <pixelsmart@sympatico.ca> wrote in message
news:Pvdub.4913$ZF1.567826@news20.bellglobal.com...
> Hello,
>
> The newest Xilinx tools will not work on Win98. My Viewdraw schematic
> capture win not work on XP so I will need to find a new schematic capture
> tool. I know that Xilinx has one but it is not powerful or user friendly.
>
> What 3rd party schematic capture tools work with the latest Xilinx tools ?
>
> Thanks
> Dan
>
>
>
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