Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 70775

Article: 70775
Subject: Re: How to add clock delay in CPLD?
From: "Repzak" <repzak@GEDhotmail.com>
Date: Mon, 28 Jun 2004 09:50:43 +0200
Links: << >>  << T >>  << A >>

"rat" <rattt@col.edu.cn> skrev i en meddelelse
news:cbnvnr$2od0$1@mail.cn99.com...
> Hi,friends,
> To meet the Tsu requirement in my design, I think I should try to add some
> clock delay to the input register, how can I do that in CPLD? (not FPGA,
> without PLL,DLL)

Hey

You could use a simple bianry counter....

bit 1 = IN
Bit 2 = In/2
Bit 3 = In/4
and so on...

Kasper



Article: 70776
Subject: Re: simprim X_FF component
From: "Niv" <niv.nospam.goaway@ntlworld.com>
Date: Mon, 28 Jun 2004 09:25:48 +0100
Links: << >>  << T >>  << A >>

> when I did my timing simulation, I got the warning message:
> # ** Warning: /X_FF SETUP  Low VIOLATION ON I WITH RESPECT TO CLK;
> #   Expected := 0.67 ns; Observed := 0.258 ns; At : 1.9 ns
>
> Can someone tell me more about the X_FF component from the simprim
> library? Or is there any link for the explanation. I failed to find
> out any in the past 60 minutes. Thanks for your help.
>
This looks like a setup & hold type violation.
Is the signal into the flip-flop asynchronous to its clock? most likely.
So pass the signal thru several stages of FFs to reduce meta stability.
You'll still get the above message though.  The massage can be turned off
but it's probably better to leave it on & check that each one really is a
meta stability issue.

(Unless of course you have an incredibly fast clock, like GHz range).

Anyway, that's what I think, others are wlecome to correct me or re-enforce!



Article: 70777
Subject: Re: How to add clock delay in CPLD?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 28 Jun 2004 21:00:03 +1200
Links: << >>  << T >>  << A >>


rat wrote:

> Hi,friends,
> To meet the Tsu requirement in my design, I think I should try to add some
> clock delay to the input register, how can I do that in CPLD? (not FPGA,
> without PLL,DLL)

It depends on your signals.
Sometimes, you can use the opposite clock edge, to ensure stable 
sampling points.
If that is too coarse, you can use delay passes, but they
need real care. Nodes can be removed/optimised away by tool flows,
or revisions in tool flows, and the delays are process dependant.
ie use only when all else fails.
-jg


Article: 70778
Subject: Re: How to add clock delay in CPLD?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 28 Jun 2004 10:13:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jim Granville <no.spam@designtools.co.nz> wrote:


: rat wrote:

: > Hi,friends,
: > To meet the Tsu requirement in my design, I think I should try to add some
: > clock delay to the input register, how can I do that in CPLD? (not FPGA,
: > without PLL,DLL)

: It depends on your signals.
: Sometimes, you can use the opposite clock edge, to ensure stable 
: sampling points.
: If that is too coarse, you can use delay passes, but they
: need real care. Nodes can be removed/optimised away by tool flows,
: or revisions in tool flows, and the delays are process dependant.
: ie use only when all else fails.

Going off- and on-chip again gives also some delay that no optimizer will
optimize away, at the expense of two pins...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 70779
Subject: XILINX GMAC Core 4.0 - HALF Duplex
From: Seyior <>
Date: Mon, 28 Jun 2004 03:49:31 -0700
Links: << >>  << T >>  << A >>
Dear All, 

In my functional simulation result of modelsim, after a frame
is transmitted by GMAC in HALF Duplex Mode, the flag 
"SUCCESSFUL_FRAME, bit 0" of Transmitter Statistics is not '1'. 
What's wrong? It will be set to '1' in FULL Duplex Mode. Please help me... 

BTW, tx_underrun, tx_retransmit, tx_collision are all zero. 

Regards, 
Seyior 



Article: 70780
Subject: GT10_PCI_EXPRESS_n
From: Petter Gustad <newsmailcomp5@gustad.com>
Date: 28 Jun 2004 13:18:42 +0200
Links: << >>  << T >>  << A >>

According to the Xilinx documentation the GT10_PCI_EXPRESS_n primitive
is only "supported for Virtex-II Pro X but not for Virtex-II or
Virtex-II Pro". Does this mean that you can't use the Virtex-II Pro in
a PCI-Express application? Is this related to the electrical idle, or
are there other reasons?

Thanks
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: 70781
Subject: Re: Newbie question -fanout of iopins in fpga
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Mon, 28 Jun 2004 14:39:33 +0200
Links: << >>  << T >>  << A >>
Hal Murray wrote:

>>what is the fanout of the IOpins in Virtex2 to devices
> 
> The details are in the data sheet.  It depends upon which
> IO standard you are using.
> 
> I haven't seen the term "fanout" in data sheets for a long time.
> It doesn't really make much sense with modern logic.
> 
> CMOS has almost 0 load current so you can drive hundreds of
> loads if you don't care about speed.  The data sheet will
> give you the switching times for a specified load capacitance.
> If you have more capacitance it takes longer.

Though, you have to care for input rise and fall time requirements
of the attached receivers.

Regards,
Mario

Article: 70782
Subject: Re: Nios stops responding to interrupts
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 28 Jun 2004 06:11:29 -0700
Links: << >>  << T >>  << A >>
Hello,

I have seen similar behaviour. What I found is that if the main loop
is very tight, the interrupt handler will not get called ... very
bizarre.

ie: if I have a main loop of:

while (1); // loop infinitely, waiting for a HW interrupt

... the ISR does not get called. However:

while (1) printf( "." ); // loop, printing a dot each time around

... allows the ISR to be called. IIRC, even doing a small delay causes
the ISR not to be called, until the delay is sufficiently large. ie:

while (1)
  for (i=0; i<DELAY; i++); // loop after waiting a bit

I verified the compiler did not optimize the delay out and that
caching was disabled.

For reasons I don't understand, the tight loop causes the calling of
the ISR to fail. Perhaps you have a similar situation.

Also make sure that the HW interrupt is asserted while outside of any
currently-running ISR, as Nios has to see it level-high.

Other than this wierd case, I haven't had ISR problems. I believe I
tested this with Nios 3.2 or maybe 3.01.

-- Pete


tns1 <tns1@cox.net> wrote in message news:<spiDc.4304$6r1.615@fed1read06>...
> QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4.
> 
> I have the Nios32 @ 30mhz working fine with my user logic modules, but 
> any ISR I try works a random number of times (1 to 30 times?) and then 
> stops getting called. By bringing out some internal signals to pins, I 
> can see that the irq signal from my module is asserted, but the ISR just 
> does not get called. This is the first time I have tried using Nios 
> interrupts, but I am getting it straight from the examples.
> 
> As a test, I wrote an ISR that just increments and prints a count value, 
> and does not clear the interrupt. There is no foreground code other than 
> installing the vector and enabling interrupts. I would expect my ISR to 
> get called indefinitely, (context save, execute, context restore), but 
> it just works a random # of times and stops.
> 
> This is the only handler I have installed, but I know the spurious 
> handler is installed by default (it works), as well as the CWP handler 
> (dont know if it works - how to test?). The behavior suggests 
> stack/memory corruption from the context save/restore. I don't re-enable 
> interrupts in my ISR, so I don't expect nested interrupts.
> 
> I have seen weird behaviors whenever the systhesis does not match the 
> assembled libraries used to compile (forgot to use 'Generate'), but I 
> have triple-checked. Any ideas/new errata?

Article: 70783
Subject: Re: Division in Xilinx
From: Jonas Floden <jonas.floden@ericsson.com>
Date: Mon, 28 Jun 2004 15:13:12 +0200
Links: << >>  << T >>  << A >>
Compile-time constants would be something like,
out <= 11 / 7;
where the compiler replaces it whit a constant like
out <= 1.5....;

and the other case when the right argument is a power of 2 is something like
out <= B / 8;
which would be replace whit a shift right
out <= B >> 3;

neither of these examples would result in any division hardware

But your example
out <= A / B;

doesn't fit either of these. If this is what you really need you would 
have to implement your own division.

Hope this helps

// Jonas


Article: 70784
Subject: Re: Nios stops responding to interrupts
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 28 Jun 2004 06:14:12 -0700
Links: << >>  << T >>  << A >>
Yes I remember now that how often the ISR was reliably called was
inversely proportional to how tight my main loop was ... ie, sometimes
I would see sporadic interrupt trapping like you are.

-- Pete

tns1 <tns1@cox.net> wrote in message news:<spiDc.4304$6r1.615@fed1read06>...
> QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4.
> 
> I have the Nios32 @ 30mhz working fine with my user logic modules, but 
> any ISR I try works a random number of times (1 to 30 times?) and then 
> stops getting called. By bringing out some internal signals to pins, I 
> can see that the irq signal from my module is asserted, but the ISR just 
> does not get called. This is the first time I have tried using Nios 
> interrupts, but I am getting it straight from the examples.
> 
> As a test, I wrote an ISR that just increments and prints a count value, 
> and does not clear the interrupt. There is no foreground code other than 
> installing the vector and enabling interrupts. I would expect my ISR to 
> get called indefinitely, (context save, execute, context restore), but 
> it just works a random # of times and stops.
> 
> This is the only handler I have installed, but I know the spurious 
> handler is installed by default (it works), as well as the CWP handler 
> (dont know if it works - how to test?). The behavior suggests 
> stack/memory corruption from the context save/restore. I don't re-enable 
> interrupts in my ISR, so I don't expect nested interrupts.
> 
> I have seen weird behaviors whenever the systhesis does not match the 
> assembled libraries used to compile (forgot to use 'Generate'), but I 
> have triple-checked. Any ideas/new errata?

Article: 70785
Subject: Programming Altera Devices
From: ALuPin@web.de (ALuPin)
Date: 28 Jun 2004 06:22:43 -0700
Links: << >>  << T >>  << A >>
Hi newsgroup users,

can someone tell me how to define the programming time of a EP1C12 Cyclone
when using PL-BYTEBLASTER2 cable in comparison to PL-USB-BLASTER cable?

Thank you for your help.


Rgds

Article: 70786
Subject: Re: How to add clock delay in CPLD?
From: "rat" <rattt@col.edu.cn>
Date: Mon, 28 Jun 2004 22:29:32 +0800
Links: << >>  << T >>  << A >>


> Going off- and on-chip again gives also some delay that no optimizer will
> optimize away, at the expense of two pins...

Good idea :) But it seems that it is hard to do the simulation and timing
analysis



Article: 70787
Subject: Re: Nios stops responding to interrupts
From: tns1 <tns1@cox.net>
Date: Mon, 28 Jun 2004 08:17:41 -0700
Links: << >>  << T >>  << A >>
I have an 8ms delay in my main loop now, and I still have the problem so 
it does not seem like the same one. I can try adding more code to my 
loop. Still, neither the behavior you describe nor the one I am seeing 
are correct so what's the root cause?

My user logic module clears the IRQ whenever I read a register. Normally 
this is done in the ISR. Eventually the IRQ does not clear because the 
ISR is not called. (This does not seem to be the case of the ISR getting 
called, but not clearing the IRQ for some reason). I tried adding a read 
of the same clearing register in my main loop every 100ms. This 'kick 
starts' the Nios when it is ignoring IRQs, but probably at a cost of a 
lost IRQ - it works, but is not acceptable.

I can also exit my main loop (via a terminal key press), and perform a 
manual read of the clearing register. This does clear the asserted IRQ 
signal, but does NOT restore the system to normal operation. Even though 
main line code runs OK, subsequent IRQs are still ignored. The only way 
to re-enable interrupts is to reset everything. This really sounds like 
an IRQ is being blocked in the Nios core kinda like interrupts were 
never re-enabled internally during the previous context restore (or 
vector table corruption or...). I guess I need to try the debugger so I 
can look at stack pointers, status registers, etc.

I read about an option on the CWP manager that selects between HW & SW 
handling of overflows on the register window but I don't see this choice 
  on any tool dialog.





Peter Sommerfeld wrote:
> Yes I remember now that how often the ISR was reliably called was
> inversely proportional to how tight my main loop was ... ie, sometimes
> I would see sporadic interrupt trapping like you are.
> 
> -- Pete
> 
> tns1 <tns1@cox.net> wrote in message news:<spiDc.4304$6r1.615@fed1read06>...
> 
>>QuartusII 4.0 SP1, SOPC builder with Nios 3.2, Cyclone C4.
>>
>>I have the Nios32 @ 30mhz working fine with my user logic modules, but 
>>any ISR I try works a random number of times (1 to 30 times?) and then 
>>stops getting called. By bringing out some internal signals to pins, I 
>>can see that the irq signal from my module is asserted, but the ISR just 
>>does not get called. This is the first time I have tried using Nios 
>>interrupts, but I am getting it straight from the examples.
>>
>>As a test, I wrote an ISR that just increments and prints a count value, 
>>and does not clear the interrupt. There is no foreground code other than 
>>installing the vector and enabling interrupts. I would expect my ISR to 
>>get called indefinitely, (context save, execute, context restore), but 
>>it just works a random # of times and stops.
>>
>>This is the only handler I have installed, but I know the spurious 
>>handler is installed by default (it works), as well as the CWP handler 
>>(dont know if it works - how to test?). The behavior suggests 
>>stack/memory corruption from the context save/restore. I don't re-enable 
>>interrupts in my ISR, so I don't expect nested interrupts.
>>
>>I have seen weird behaviors whenever the systhesis does not match the 
>>assembled libraries used to compile (forgot to use 'Generate'), but I 
>>have triple-checked. Any ideas/new errata?



Article: 70788
Subject: Re: Family Photo Album
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 28 Jun 2004 08:25:52 -0700
Links: << >>  << T >>  << A >>

Finn,

I take issue with the unsupported spin by competitors accusing us of 
introducing a product "too early."

First of all, very few products get introduced totally problem free. 
Yes, we have had an errata sheet with a new product, but that is a 
service, not something to be ashamed of.  In fact, compared to others in 
this industry, our errata sheet is at least less than a couple of pages, 
and most often a single sheet.  Others have in excess of 20 or more 
known bugs, with many different mask revisions, which is hell to keep 
track of.  So are we too early when we have a few errata, but we do not 
force a customer to live through three mask revisions?  That to me is 
too early:  announcing a product that is too buggy, and isn't ready. 
What does it matter that it is "on the shelf?"

Secondly, there has been incredible unexpected business in Spartan 3. 
So, did we not have enough supply?  Yes.  Did we intentionally introduce 
it too early so we would make people unhappy?  No.

Third, I can say nothing about the software (not my area), so no defense 
offered here.  I will let them offer one, or an apology, whichever is 
appropriate.

Fourth, and lastly, Virtex 4 was announced today being shipped to early 
access customers.  That means it is real.  Now comes the fun part, 
making lots more, and sampling them.  I will not disagree that the 
sampling phase will be a real challenge, but who else has a triple oxide 
500 MHz FPGA with IBM Power PC's, 10 Gbs transceivers, FIFO BRAM, 48bit 
DSP with MAC...... no one.  It isn't called the "bleeding edge" for nothing.

But if you are not there (on the edge of the technology juggernaut), you 
are nowhere.


Austin

Article: 70789
Subject: Re: How to add clock delay in CPLD?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 28 Jun 2004 16:15:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
rat <rattt@col.edu.cn> wrote:


: > Going off- and on-chip again gives also some delay that no optimizer will
: > optimize away, at the expense of two pins...

: Good idea :) But it seems that it is hard to do the simulation and timing
: analysis

Put the delay, taken from the data sheet, into the test bench...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 70790
Subject: Re: 5V board in a 3.3V PCI slot
From: Dwayne Surdu-Miller <miller@SEDsystems.nospam.ca>
Date: Mon, 28 Jun 2004 10:21:17 -0600
Links: << >>  << T >>  << A >>
We had to fix our first prototype the same way... a "universal solution" :-)


Article: 70791
Subject: Re: Using a BlockRam in an async FIFO for bus width conversion ?
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 28 Jun 2004 09:33:05 -0700
Links: << >>  << T >>  << A >>
You can treat the inputs to the BlockRAM just as if it were a register.
Give it all its information and then apply the right clock edge. It's as
simple as that.

But an asynchronous FIFO is not simple, especially if you are after high
clock rates. The problem is detecting EMPTY reliably, and that involves the
use of Gray counters etc.
As you may have read in today's press announcement, we took care of that in
Virtex-4, where we incorporated a FIFO controller with all the bells and
whistles and impressive speed...
Peter Alfke

> From: "Arnaud" <arnaud@trisky.com>
> Organization: Guest of ProXad - France
> Newsgroups: comp.arch.fpga,comp.lang.vhdl
> Date: Sat, 26 Jun 2004 09:34:40 +0200
> Subject: Re: Using a BlockRam in an async FIFO for bus width conversion ?
> 
> Thanks Peter,
> 
> I was thinking,the behaviour was:
> - on the clock_write rising edge : I setup Address, data, Write Enable and
> ENable, as setup time is not valid, BlockRam doesn't take them into account
> - on the next clock_write rising edge, I setup the new value, and the
> BlockRam gets the previous value (line above), and set the memory cell
> - and so on..
> 
> It works fine in behavioral not in post place and route, it seems, that some
> part of the value changed at the rising edge are taken from the "before
> rising edge" values, while others are taken from the "after rising edge"
> values, in post place and route.
> 
> To do what you told me "at least a set-up time before", I changed my block
> Ram to react on FallingEdge, while my logical set all the values at the
> RisingEdge....
> But I don't know if it's the "good way"...
> 
> I didn't succeed to find any trivial example about the use of DualPort
> BlockRam... if anyone has one, I would love to get it.
> 
> Many thanks,
> 
> Arnaud
> 
> "Peter Alfke" <peter@xilinx.com> a écrit dans le message de
> news:BD01EB55.71BA%peter@xilinx.com...
>> Remember, all BlockRAM operations are synchronous, activated by the clock
>> edge (your choice of clock polarity).
>> That means all inputs must be there at least a set-up time before that
> clock
>> edge.
>> "All" means: Address, Data, Write Enable, and ENable.
>> 
>> Peter Alfke, Xilinx Applications
>> 
>>> From: "Arnaud" <arnaud@trisky.com>
>>> Organization: Guest of ProXad - France
>>> Newsgroups: comp.arch.fpga,comp.lang.vhdl
>>> Date: Fri, 25 Jun 2004 22:11:03 +0200
>>> Subject: Using a BlockRam in an async FIFO for bus width conversion ?
>>> 
>>> Hi all,
>>> First of all, I'm a newbie in FPGA, so sorry if my questions are not
> very
>>> smart... :-)
>>> In a larger design, I try to use a Xilinx BlockRam for a data width
>>> conversion between 2 clocks domains.
>>> I look through the different Xilinx example (xapp131, xapp258, ..). As
> my
>>> needs was much more simpler I try to make mine (mostly to understand).
>>> 
>>> During behavioral or post-translate simulation everything is ok. But
> during
>>> Post-Place & Route Simulation. It doesn't work.
>>> I try 2 write 2 32bits words from one side and to get on the other side
> a
>>> 64bits word.
>>> In my test bench, I write
>>> 1st -  0x00000000 and 0x00000001
>>> and the read side I get 0x0000000100000000
>>> 2nd - 0x00000002 and 0x00000003
>>> and the read side I get 0x0000000300000002
>>> and so on.
>>> 
>>> BUT in place and route simulation I have
>>> In my test bench, I write
>>> 1st -  0x00000000 and 0x00000001
>>> and the read side I get 0x0000000000000000
>>> 2nd - 0x00000002 and 0x00000003
>>> and the read side I get 0x0000000200000001
>>> 2nd - 0x00000004 and 0x00000005
>>> and the read side I get 0x0000000400000003
>>> and so on.
>>> 
>>> 
>>> Basically, I always miss the first value, as It is not taken into
> account,
>>> and the "word" are reordered (so with the wrong pair association).
>>> 
>>> I saw on the newsgroups, that maybe I have to set the WriteEnable
> _before_
>>> the rising edge, but I don't understand how and why if it's the case ?
>>> 
>>> I have isolated my problem in the two following file (testbench and
>>> "converter")
>>> 
>>> Thanks a lot.
>>> 
>>> Arnaud
>>> 
>>> 
>>> 
>>> Converter
>> 
>> --------------------------------------------------------------------------
> --
>>> ----------------------------
>>> library IEEE;
>>> use IEEE.STD_LOGIC_1164.ALL;
>>> use IEEE.STD_LOGIC_ARITH.ALL;
>>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>>> 
>>> --  Uncomment the following lines to use the declarations that are
>>> --  provided for instantiating Xilinx primitive components.
>>> library UNISIM;
>>> use UNISIM.VComponents.all;
>>> 
>>> entity test_fifo is
>>> Port ( clk_wr_in : in std_logic;
>>> clk_rd_in : in std_logic;
>>> bus_in : in std_logic_vector(31 downto 0);
>>> bus_out : out std_logic_vector(63 downto 0);
>>> wr : in std_logic;
>>> rd : in std_logic;
>>> sr : in std_logic);
>>> end test_fifo;
>>> 
>>> architecture Behavioral of test_fifo is
>>> 
>>> component bram_w32_r64
>>> port (
>>> addra: IN std_logic_VECTOR(4 downto 0);
>>> addrb: IN std_logic_VECTOR(3 downto 0);
>>> clka: IN std_logic;
>>> clkb: IN std_logic;
>>> dina: IN std_logic_VECTOR(31 downto 0);
>>> doutb: OUT std_logic_VECTOR(63 downto 0);
>>> ena: IN std_logic;
>>> enb: IN std_logic;
>>> wea: IN std_logic);
>>> end component;
>>> 
>>> 
>>> signal    addra: std_logic_VECTOR(4 downto 0);
>>> signal    addrb: std_logic_VECTOR(3 downto 0);
>>> 
>>> 
>>> 
>>> signal    clk_rd: std_logic;
>>> signal    clk_wr: std_logic;
>>> 
>>> signal rst : std_logic;
>>> 
>>> begin
>>> 
>>> 
>>> gclk1: BUFGP port map (I => clk_rd_in, O => clk_rd);
>>> gclk2: BUFGP port map (I => clk_wr_in, O => clk_wr);
>>> 
>>> rst <= not sr;
>>> 
>>> bram : bram_w32_r64
>>> port map (
>>> addra => addra,
>>> addrb => addrb,
>>> clka => clk_wr,
>>> clkb => clk_rd,
>>> dina => bus_in,
>>> doutb => bus_out,
>>> ena => wr,
>>> enb => rst,
>>> wea => '1');
>>> 
>>> 
>>> writer: process(sr, clk_wr)
>>> begin
>>> if ( sr = '1' ) then
>>> 
>>> addra <= (others => '0');
>>> 
>>> elsif (rising_edge(clk_wr)) then
>>> 
>>> if ( wr = '1' ) then
>>> addra <= addra + 1  ;
>>> end if;
>>> 
>>> end if;
>>> 
>>> end process writer;
>>> 
>>> 
>>> 
>>> reader: process(sr, clk_rd)
>>> begin
>>> if ( sr = '1' ) then
>>> 
>>> addrb <= (others => '0');
>>> 
>>> elsif (rising_edge(clk_rd)) then
>>> if (rd = '1') then
>>> addrb <= addrb + 1  ;
>>> end if;
>>> 
>>> end if;
>>> 
>>> end process reader;
>>> 
>>> end Behavioral;
>>> 
>>> 
>>> TEST_BENCH
>> 
>> --------------------------------------------------------------------------
> --
>>> ----------------------------
>>> LIBRARY ieee;
>>> USE ieee.std_logic_1164.ALL;
>>> USE ieee.numeric_std.ALL;
>>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>>> 
>>> 
>>> ENTITY test_fifo_tb IS
>>> END test_fifo_tb;
>>> 
>>> ARCHITECTURE behavior OF test_fifo_tb IS
>>> 
>>> COMPONENT test_fifo
>>> PORT(
>>> clk_wr_in : IN std_logic;
>>> clk_rd_in : IN std_logic;
>>> bus_in : IN std_logic_vector(31 downto 0);
>>> bus_out : out std_logic_vector(63 downto 0);
>>> wr : IN std_logic;
>>> rd : IN std_logic;
>>> sr : IN std_logic
>>> );
>>> END COMPONENT;
>>> 
>>> SIGNAL clk_wr :  std_logic := '0';
>>> SIGNAL clk_rd :  std_logic := '0';
>>> SIGNAL bus_in :  std_logic_vector(31 downto 0):= (others => '0');
>>> SIGNAL bus_out :  std_logic_vector(63 downto 0):= (others => '0');
>>> SIGNAL wr :  std_logic :='0';
>>> SIGNAL rd :  std_logic := '0';
>>> SIGNAL sr :  std_logic := '1';
>>> 
>>> BEGIN
>>> 
>>> uut: test_fifo PORT MAP(
>>> clk_wr_in => clk_wr,
>>> clk_rd_in => clk_rd,
>>> bus_in => bus_in,
>>> bus_out => bus_out,
>>> wr => wr,
>>> rd => rd,
>>> sr => sr
>>> );
>>> 
>>> 
>>> -- *** Test Bench - User Defined Section ***
>>> 
>>> clk_wr <= not clk_wr after 30 ns / 2;
>>> clk_rd <= not clk_rd after 15 ns / 2;
>>> sr <= transport '0' after 120 ns;
>>> 
>>> tb : PROCESS
>>> BEGIN
>>> wait; -- will wait forever
>>> END PROCESS;
>>> -- *** End Test Bench - User Defined Section ***
>>> 
>>> writer: process( clk_wr, sr)
>>> begin
>>> 
>>> if ( sr ='1' ) then
>>> 
>>> bus_in <= (others => '1');
>>> 
>>> elsif (rising_edge(clk_wr)) then
>>> 
>>> if ( bus_out /= 8 ) then
>>> rd <= '0';
>>> wr <= '1';
>>> bus_in <= bus_in + 1;
>>> else
>>> wr <= '0';
>>> rd <= '1';
>>> end if;
>>> 
>>> end if;
>>> 
>>> end process writer;
>>> END;
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 


Article: 70792
Subject: Re: GT10_PCI_EXPRESS_n
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Mon, 28 Jun 2004 10:01:34 -0700
Links: << >>  << T >>  << A >>

Hello,

> According to the Xilinx documentation the GT10_PCI_EXPRESS_n
> primitive is only "supported for Virtex-II Pro X but not for
> Virtex-II or Virtex-II Pro".

The GT10_PCI_EXPRESS_n primitives are based on the GT10
primitive that is only available in Virtex-II ProX.  The
protocol specific primitives are "convenience macros"
that use the transceiver primitives and have all the
attributes set for the specific protocol, so you don't
need to figure it out yourself.

In Virtex-II Pro, you can use the GT primitive, and there
are some "convenience macros" for ethernet, fibre channel,
and infiniband.  However, there isn't one for PCI Express,
so you would need to use the GT primitive and then set
all the attributes to get the desired result.

Your next question would probably be, "Why?" and I'm not
sure so I'll file an enhancement CR on this issue.  I suspect
it is due to the Virtex-II Pro library being developed before
PCI Express specifications were final.  (And this is not the
case for Virtex-II ProX...)

> Does this mean that you can't use the Virtex-II Pro in
> a PCI-Express application?

No.  You can use Virtex-II Pro for PCI Express, and we do!
If you want to read more about it, you can check out our
IP datasheet for the PCI Express endpoint core, at:

http://www.xilinx.com/systemio/pciexpress/index.htm

> Is this related to the electrical idle, or are there
> other reasons?

Unrelated.

Hope that helps,
Eric

Article: 70793
Subject: Re: Family Photo Album
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 28 Jun 2004 13:38:06 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> I am told that distributors do have part/package combinations in stock
> on the shelf.  I am also told that some devices are still in short
> supply.  We are fab'ing as many wafers as we possibly can to catch up
> (projecting ahead), but demand is ramping faster.

I asked for an update on the XC3S400-4FG456C and was told 12 weeks
(that's three months, right?) or "open order entry" for the ES version. 
They did not say they had had even the ES parts on the shelf.  Can you
give me a heads up on who might have stock on this part?  

Also, what exactly is the difference between the production and ES parts
at this point?  I believe the 3S400 parts are claimed to be in
"production" for many months now.  Where do the ES parts come from at
this late stage? 



> PS:  I did not intend to put "words in your mouth".  Poetic license
> #23210098 issued 5/14/53

When replying to my posts, please keep your poetic license in your
pocket.  This is prose, not poetry.  :) 

-- 

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 FAX

Article: 70794
Subject: Battle of the Vapours
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 28 Jun 2004 20:03:20 +0100 (BST)
Links: << >>  << T >>  << A >>
OK, the next-generation parts at both application grades from both
manufacturers are now announced. I've not been around for long enough
to know how long to expect between announcement and availability at
the hobbyist level; is Christmas 2005 for Cyclone II (announced today)
dev boards reasonable?

It's nice to see reasonably serious levels of DSP appearing at the
low-end parts, though I'm a little disappointed that we're not seeing
seas of floating-point units in the high end, even in the Virtex 4SX;
those can be so much smaller as macrocells than built out of logic.

What _is_ the business about "maximum toggle frequency 500MHz (for
export control)" in the Spartan3 datasheet?

I was contemplating real-time fractal generators, and it's not clear
that a 4+50 x 4+50 -> 4+50 fixed-point triple-precision multiplier
built in a Spartan 3 would be price-competitive with small piles of
PCs; rough summing of propagation delays suggest you can get three,
with 10-15ns propagation, into an XC3S1000. Which is 200-300Mflops,
and with small-volume costs and board-building charges I don't see I
could get the price below the $100 required to compete on
price/performance with Athlon64.

Whatever happens, these will be wonderful things to play with; many
thanks to everybody involved in bringing on the Era of Programmable
Hardware!

Tom

Article: 70795
Subject: FPGA jobs in Germany
From: lenz19@gmx.de (lenz)
Date: 28 Jun 2004 13:00:28 -0700
Links: << >>  << T >>  << A >>
Hi,

I will finish the University within the next months. Now I am looking
for companies in Germany in the field of FPGA. 

I have found some companies specialized in FPGA design and consulting
- El Camino
- Polar Design
- Array Electronics

Are there any other FPGA design/consulting companys in Germany ?
Which companys employ FPGAs in their products and therefore could
be a potential employer for me ?

Thank you very much.

Article: 70796
Subject: Re: Battle of the Vapours
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 28 Jun 2004 13:24:24 -0700
Links: << >>  << T >>  << A >>


> From: Thomas Womack <twomack@chiark.greenend.org.uk>
> Organization: Linux Unlimited
> Newsgroups: comp.arch.fpga
> Date: 28 Jun 2004 20:03:20 +0100 (BST)
> Subject: Battle of the Vapours
> 
> > What _is_ the business about "maximum toggle frequency 500MHz (for
> export control)" in the Spartan3 datasheet?
> 
There are restrictions on exporting (from the US) devices above a certain
level of sophistication. And the government measures that as toggle rate.
(The idea was to avoid helping the "evil empire" develop better missile
guidance systems).
The Cold War lives forever...
Peter Alfke


Article: 70797
Subject: Re: Family Photo Album
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 28 Jun 2004 13:31:40 -0700
Links: << >>  << T >>  << A >>
Rick,

---snip----

 > I asked for an update on the XC3S400-4FG456C and was told 12 weeks
> (that's three months, right?) or "open order entry" for the ES version. 
> They did not say they had had even the ES parts on the shelf.  Can you
> give me a heads up on who might have stock on this part?

Sorry, I suspect that S3 ES parts are available only through Xilinx, 
which means that we have stock, and are awaiting a disti order.  Only 
those disti's that want to (we can not force them) will buy ES material, 
as they do not want to be "stuck" with ES stock (as then they have to 
write it).

> Also, what exactly is the difference between the production and ES parts
> at this point?

Basically none.  After the first masks of the first family members, 
errata are fixed, and the second or third masks made are just awaiting 
the HTOL (high temperature operating life), ESD, and other reliability 
tests before they can be officially called production.  Same silicon, 
more paper pedigree.  Again, contact you disti and FAE for exact details 
on any specific part.  One good way is to request the errata sheet for 
the two parts.  If there is no errata sheet for a part, it has no 
problems, and that usually means it is the second mask made in the 
family, as the first one's errata are fixed (if any).

> I believe the 3S400 parts are claimed to be in
> "production" for many months now.  Where do the ES parts come from at
> this late stage? 

As soon as we have production, no one wants the ES anymore.  Sometimes 
we have to write off a lot of ES material as it can not be sold (or 
donate it to schools and universities -- see the Xilinx University 
Program online!  Do not email me for the parts!).

Article: 70798
Subject: Re: Battle of the Vapours
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 28 Jun 2004 22:49:13 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <BD05CC88.7201%peter@xilinx.com>,
Peter Alfke  <peter@xilinx.com> wrote:
>
>
>> From: Thomas Womack <twomack@chiark.greenend.org.uk>
>> Organization: Linux Unlimited
>> Newsgroups: comp.arch.fpga
>> Date: 28 Jun 2004 20:03:20 +0100 (BST)
>> Subject: Battle of the Vapours
>> 
>> > What _is_ the business about "maximum toggle frequency 500MHz (for
>> export control)" in the Spartan3 datasheet?
 
>There are restrictions on exporting (from the US) devices above a certain
>level of sophistication. And the government measures that as toggle rate.
>(The idea was to avoid helping the "evil empire" develop better missile
>guidance systems).

OK, I suppose that makes a certain degree of sense; I wonder slightly
how the big microprocessor vendors get round that issue. There were
those Apple adverts saying that their machine was by export-control
standards a supercomputer, but I've seen plenty of dual-G5 boxes on
my side of the Atlantic.

With my Dr Evil hat on, I wonder slightly how you set a maximum toggle
frequency when the LUT propagation time is already down to 700ps or so
-- I wonder if it's a matter of refraining from heroic engineering
efforts to keep parasitic capacitance down in the flip-flops, or a
couple of lines in the depths of the hardware-compiler?

Tom

Article: 70799
Subject: Re: Battle of the Vapours
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 29 Jun 2004 09:55:44 +1200
Links: << >>  << T >>  << A >>
Thomas Womack wrote:
> OK, the next-generation parts at both application grades from both
> manufacturers are now announced. I've not been around for long enough
> to know how long to expect between announcement and availability at
> the hobbyist level; is Christmas 2005 for Cyclone II (announced today)
> dev boards reasonable?

Probably, as Altera mention Q2 2005 for samples of most devices.

Lattice also have a new family, with their prices quoted at 1K
( compared with the others of 18 months out, and asymptope volumes :)
Lattice also say first samples in July 2004, (yes, next month, not
next year...)


> It's nice to see reasonably serious levels of DSP appearing at the
> low-end parts, though I'm a little disappointed that we're not seeing
> seas of floating-point units in the high end, even in the Virtex 4SX;
> those can be so much smaller as macrocells than built out of logic.
> 
> What _is_ the business about "maximum toggle frequency 500MHz (for
> export control)" in the Spartan3 datasheet?
> 
> I was contemplating real-time fractal generators, and it's not clear
> that a 4+50 x 4+50 -> 4+50 fixed-point triple-precision multiplier
> built in a Spartan 3 would be price-competitive with small piles of
> PCs; rough summing of propagation delays suggest you can get three,
> with 10-15ns propagation, into an XC3S1000. Which is 200-300Mflops,
> and with small-volume costs and board-building charges I don't see I
> could get the price below the $100 required to compete on
> price/performance with Athlon64.

AMD has announced a lower cost MPU, still no word on Price/Bits, but it
will be real well in advance of the vapor-FPGAs.
Hard to imagine it not being 64bit, given the [marketing 
advantage/silicon cost] ratios...
-jg





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search