EDK : FSL macros defined by Xilinx are wrong

[MM]

"Vagant" <vladimir.v.korostelev@rambler.ru> wrote in message
news:63eb6286-cf11-476b-90d2-c44e93c343c4@x35g2000hsb.googlegroups.com...

My problem is that I do not understand how to establish a connection
between an output of signal generator (which is RF connector) and an
input of ADC which is one of FPGA pins as they are physically
incompatible.

What are you talking about? There are no ADCs in Spartan-3E! You can make a
delta-sigma one yourself
(http://www.xilinx.com/support/documentation/ip_documentation/xps_deltasigma_adc.pdf),
but I doubt you can make it run fast enough for any RF application...
Usually an ADC is an external component.


/Mikhail

 

[Brad Smallridge]

I have camera link working at 40MHz, a 2 meter cable,
VHDL code using the ISERDES Xilinx primitives, a ML402
with a daughter board of my own design that had matched
length traces.

I did not use Digital Control Impedance.

What do you mean "one end open"?

Setting up the ISERDES,the terminated IOBs, and your
DCMs are all critical:

from UCF file:
# CAMERA LINK 2 INPUT
NET "cam2_in<0>" LOC = "AC20" ; # X0NEG
NET "cam2_in<1>" LOC = "AB20" ; # X0POS
NET "cam2_in<2>" LOC = "AD21" ; # X1NEG
NET "cam2_in<3>" LOC = "AE21" ; # X1POS
NET "cam2_in<4>" LOC = "AD20" ; # X2NEG
NET "cam2_in<5>" LOC = "AE20" ; # X2POS
NET "cam2_in<6>" LOC = "AC19" ; # CLKNEG
NET "cam2_in<7>" LOC = "AD19" ; # CLKPOS
NET "cam2_in<8>" LOC = "AB18" ; # X3NEG
NET "cam2_in<9>" LOC = "AC18" ; # X3POS

from VHDL:

attribute DIFF_TERM : boolean;
attribute DIFF_TERM of cam2_x0_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_x1_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_x2_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_x3_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_xclk_ibufd_inst:label is true;
attribute DIFF_TERM of serial_from_cam2_IBUFDS:label is true;

cam2_xclk_ibufd_inst : IBUFDS
port map (
O => cam2_xclk,
I => cam2_in(7),
IB => cam2_in(6) );

cam2_x0_ibufd_inst : IBUFDS
port map (
O => cam2_x0,
I => cam2_in(1),
IB => cam2_in(0) );

cam2_x1_ibufd_inst : IBUFDS
port map (
O => cam2_x1,
I => cam2_in(3),
IB => cam2_in(2) );

cam2_x2_ibufd_inst : IBUFDS
port map (
O => cam2_x2,
I => cam2_in(5),
IB => cam2_in(4) );

cam2_x3_ibufd_inst : IBUFDS
port map (
O => cam2_x3,
I => cam2_in(9),
IB => cam2_in(8) );


iserdes_master : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain
"NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => dout(0),
Q2 => dout(1),
Q3 => dout(2),
Q4 => dout(3),
Q5 => dout(4),
Q6 => dout(5),
SHIFTOUT1 => shift1,
SHIFTOUT2 => shift2,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => fclk,
CLKDIV => xclk,
D => din,
DLYCE => dlyce,
DLYINC => dlyinc,
DLYRST => dlyrst,
OCLK => oclk,
REV => '0',
SHIFTIN1 => '0',
SHIFTIN2 => '0',
SR => reset );

iserdes_slave : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain
"NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => open,
Q2 => open,
Q3 => dout(6),
Q4 => dout(7),
Q5 => dout(8),
Q6 => dout(9),
SHIFTOUT1 => open,
SHIFTOUT2 => open,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => fclk,
CLKDIV => xclk,
D => '0',
DLYCE => dlyce,
DLYINC => dlyinc,
DLYRST => dlyrst,
OCLK => oclk,
REV => '0',
SHIFTIN1 => shift1,
SHIFTIN2 => shift2,
SR => reset );

Brad Smallridge
AiVision

<Crhonos04@gmail.com> wrote in message
news:aaab7574-dcb3-49ce-a927-9ecb5926d1a0@34g2000hsf.googlegroups.com...

Hello,

I've implemented a camera link deserializer interface based on a
virtex 4 FPGA (using ML402 development board). I'm using the LVDS 2.5
V inputs of the board and a cable with one end open.

The module works fine when i use a short cable. However, my
application needs to use a long cable (with a discontinuity) which
doesn't work so fine. The thing is that I guess there is a match
problem in the board reception side, because when i represent the eye
diagram of the incoming signals (once it's converted to LVTTL) and the
long cable is used, it's really bad.

I know that it is possible to use this long cable because it works
with a generic frame grabber.
I've tried using the DCI (Digital Control impedance) of the FPGA,
LVDS_EXT standard... but i don't reach a solution...

If someone could have some experience in this field...

Thank very much in advace !

 

[Brad Smallridge]

I have camera link working at 40MHz, a 2 meter cable,
VHDL code using the ISERDES Xilinx primitives, a ML402
with a daughter board of my own design that had matched
length traces.

I did not use Digital Control Impedance.

What do you mean "one end open"?

Setting up the ISERDES,the terminated IOBs, and your
DCMs are all critical:

from UCF file:
# CAMERA LINK 2 INPUT
NET "cam2_in<0>" LOC = "AC20" ; # X0NEG
NET "cam2_in<1>" LOC = "AB20" ; # X0POS
NET "cam2_in<2>" LOC = "AD21" ; # X1NEG
NET "cam2_in<3>" LOC = "AE21" ; # X1POS
NET "cam2_in<4>" LOC = "AD20" ; # X2NEG
NET "cam2_in<5>" LOC = "AE20" ; # X2POS
NET "cam2_in<6>" LOC = "AC19" ; # CLKNEG
NET "cam2_in<7>" LOC = "AD19" ; # CLKPOS
NET "cam2_in<8>" LOC = "AB18" ; # X3NEG
NET "cam2_in<9>" LOC = "AC18" ; # X3POS

from VHDL:

attribute DIFF_TERM : boolean;
attribute DIFF_TERM of cam2_x0_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_x1_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_x2_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_x3_ibufd_inst:label is true;
attribute DIFF_TERM of cam2_xclk_ibufd_inst:label is true;
attribute DIFF_TERM of serial_from_cam2_IBUFDS:label is true;

cam2_xclk_ibufd_inst : IBUFDS
port map (
O => cam2_xclk,
I => cam2_in(7),
IB => cam2_in(6) );

cam2_x0_ibufd_inst : IBUFDS
port map (
O => cam2_x0,
I => cam2_in(1),
IB => cam2_in(0) );

cam2_x1_ibufd_inst : IBUFDS
port map (
O => cam2_x1,
I => cam2_in(3),
IB => cam2_in(2) );

cam2_x2_ibufd_inst : IBUFDS
port map (
O => cam2_x2,
I => cam2_in(5),
IB => cam2_in(4) );

cam2_x3_ibufd_inst : IBUFDS
port map (
O => cam2_x3,
I => cam2_in(9),
IB => cam2_in(8) );


iserdes_master : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain
"NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => dout(0),
Q2 => dout(1),
Q3 => dout(2),
Q4 => dout(3),
Q5 => dout(4),
Q6 => dout(5),
SHIFTOUT1 => shift1,
SHIFTOUT2 => shift2,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => fclk,
CLKDIV => xclk,
D => din,
DLYCE => dlyce,
DLYINC => dlyinc,
DLYRST => dlyrst,
OCLK => oclk,
REV => '0',
SHIFTIN1 => '0',
SHIFTIN2 => '0',
SR => reset );

iserdes_slave : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain
"NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => open,
Q2 => open,
Q3 => dout(6),
Q4 => dout(7),
Q5 => dout(8),
Q6 => dout(9),
SHIFTOUT1 => open,
SHIFTOUT2 => open,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => fclk,
CLKDIV => xclk,
D => '0',
DLYCE => dlyce,
DLYINC => dlyinc,
DLYRST => dlyrst,
OCLK => oclk,
REV => '0',
SHIFTIN1 => shift1,
SHIFTIN2 => shift2,
SR => reset );

Brad Smallridge
AiVision

<Crhonos04@gmail.com> wrote in message
news:aaab7574-dcb3-49ce-a927-9ecb5926d1a0@34g2000hsf.googlegroups.com...

Hello,

I've implemented a camera link deserializer interface based on a
virtex 4 FPGA (using ML402 development board). I'm using the LVDS 2.5
V inputs of the board and a cable with one end open.

The module works fine when i use a short cable. However, my
application needs to use a long cable (with a discontinuity) which
doesn't work so fine. The thing is that I guess there is a match
problem in the board reception side, because when i represent the eye
diagram of the incoming signals (once it's converted to LVTTL) and the
long cable is used, it's really bad.

I know that it is possible to use this long cable because it works
with a generic frame grabber.
I've tried using the DCI (Digital Control impedance) of the FPGA,
LVDS_EXT standard... but i don't reach a solution...

If someone could have some experience in this field...

Thank very much in advace !

 

[Symon]

<bamboutcha9999@hotmail.com> wrote in message
news:afb6208d-51ba-477c-b73d-b26da449b4f7@x35g2000hsb.googlegroups.com...

Hi ,

My question is silly but i need answers !

=> what do we mean by saying " distributed RAM" inside FPGA ?
what's the difference between "bistributed RAM" and BRAM inside
FPGA ?

thank you

http://www.xilinx.com/support/documentation/user_guides/ug070.pdf

 

[Symon]

<bamboutcha9999@hotmail.com> wrote in message
news:afb6208d-51ba-477c-b73d-b26da449b4f7@x35g2000hsb.googlegroups.com...

Hi ,

My question is silly but i need answers !

=> what do we mean by saying " distributed RAM" inside FPGA ?
what's the difference between "bistributed RAM" and BRAM inside
FPGA ?

thank you

http://www.xilinx.com/support/documentation/user_guides/ug070.pdf

 

[David Spencer]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:n80r245qv80dkgd4tqgehe2ots8ikfgcd9@4ax.com...

On Fri, 16 May 2008 04:39:40 -0700 (PDT), Pablo <pbantunez@gmail.com
wrote:

On 16 mayo, 12:28, backhus <n...@nirgends.xyz> wrote:
Hi Pablo;
Problem No.1: You are not able to read and understand error messages.
Problem No.2: You have not understood that errors are caused by what's
written in the source code.

Really now, how do you expect that anyone can help you with the error
message when you do not provide the source code that caused the error?

When the message says "Index out of range", well, then there must be
some index in your sources out of the allowed numerical range.

Have a nice synthesis
Eilert

what I don't understand is why ISE doesn't specify "the error signal/
constant". Usually, ise tells the "error line", but in this kind it
doesn't specify anything about a source code (which contains 800
lines).

What I don't understand is how this design passed simulation tests
without catching something as basic as an out of range index.

But anyway, if you can't find an error in an 800-line source file, split
it into two (or more) smaller source files, and find out which one
contains the error.

Repeat until error found.

- Brian

Is this a source error though? The error message quoted was:

ERROR:Xst - Xst_HdlConst_Imp::GetArrayValueByIndex : index out of
range.
ERROR:Xst - Unexpected error found while building hierarchy.

This implies that something failed in a function called
"GetArrayValueByIndex". This, combined with the lack of a line number,
suggests to me that this is an internal run-time error from XST, not a
source error, that is being reported.

 

[Joseph H Allen]

In article <g0k5da$7nq14@cnn.xsj.xilinx.com>,
austin <austin@xilinx.com> wrote:

Altera also states that if their parts latch-up (and they do, just
search for 'latch up' on their web site), that you, the customer have
screwed up, and it is all your fault for "allowing" some overshoot or
undershoot....

http://www.altera.com/literature/ds/dsoprq.pdf

page 4 (also note how they latch up due to power supply sequencing, etc.)

Careful, this note is quite old (1999). Newer parts do not have power
sequencing requirements: read the hot socketing section of any recent Altera
chip device handbook.

On the other hand, the 65nm Cyclone-III/Stratix-III 3.3v issue still
remains. Basically if you want to use 3.3V PCI on Cyclone-III, use a 3.0V
power supply.

2.5V is increasingly becomming the new 3.3V (or 5.0V).

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Joseph H Allen]

In article <g0k5da$7nq14@cnn.xsj.xilinx.com>,
austin <austin@xilinx.com> wrote:

Altera also states that if their parts latch-up (and they do, just
search for 'latch up' on their web site), that you, the customer have
screwed up, and it is all your fault for "allowing" some overshoot or
undershoot....

http://www.altera.com/literature/ds/dsoprq.pdf

page 4 (also note how they latch up due to power supply sequencing, etc.)

Careful, this note is quite old (1999). Newer parts do not have power
sequencing requirements: read the hot socketing section of any recent Altera
chip device handbook.

On the other hand, the 65nm Cyclone-III/Stratix-III 3.3v issue still
remains. Basically if you want to use 3.3V PCI on Cyclone-III, use a 3.0V
power supply.

2.5V is increasingly becomming the new 3.3V (or 5.0V).

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Brad Smallridge]

About the cable, is 5 meters in length. The problem is that there is
an intermediate sub-D connector which is joining two 2.5 m cables

I'm not sure you can daisy chain Camera Link Cables like this. Are
you doing that for the frame grabber set up? There was something
about the Camera Link spec that made me think that you can't connect
them like other cables, besides the fact they don't have male/female
connectors. Your signals maybe mirrored.

idest
?

Brad Smallridge
AiVision

 

[Brad Smallridge]

About the cable, is 5 meters in length. The problem is that there is
an intermediate sub-D connector which is joining two 2.5 m cables

I'm not sure you can daisy chain Camera Link Cables like this. Are
you doing that for the frame grabber set up? There was something
about the Camera Link spec that made me think that you can't connect
them like other cables, besides the fact they don't have male/female
connectors. Your signals maybe mirrored.

idest
?

Brad Smallridge
AiVision

 

[Symon]

The trick is knowing how small..

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:3fudnQrFX4_ku7PVnZ2dnUVZ_gednZ2d@comcast.com...

Wouldn't a small capacitor hold it low long enough?

 

[Symon]

"Jon Elson" <elson@wustl.edu> wrote in message
news:482B33EB.6080206@wustl.edu...

John_H wrote:
Aren't we?

I did mine in 2001, been happy with it since. But, it is proprietary,
and I don't intend to publish it. (sorry)

Jon

Jon,

I have discovered a truly marvellous encoder, which this newsgroup is too
narrow to contain.

Cheers, Syms.

p.s.
http://en.wikipedia.org/wiki/Fermat's_last_theorem#Fermat.27s_Last_Theorem_from_a_comment_in_a_margin

 

[Symon]

"Jon Elson" <elson@wustl.edu> wrote in message
news:482B33EB.6080206@wustl.edu...

John_H wrote:
Aren't we?

I did mine in 2001, been happy with it since. But, it is proprietary,
and I don't intend to publish it. (sorry)

Jon

Jon,

I have discovered a truly marvellous encoder, which this newsgroup is too
narrow to contain.

Cheers, Syms.

p.s.
http://en.wikipedia.org/wiki/Fermat's_last_theorem#Fermat.27s_Last_Theorem_from_a_comment_in_a_margin

 

[Göran Bilski]

Hi,

MicroBlaze in EDK 9.2 can use either PLB46 or OPB.
There is a new parameter "C_INTERCONNECT" on MicroBlaze which specify what
bus standard to use.
The default value is PLB46 so if you port a design that is using OPB, make
sure that this parameter is set for OPB.

Göran

"wicky" <wicky.zhang@gmail.com> wrote in message
news:bc03051e-9376-408d-a0f7-326c8ccbee6f@b5g2000pri.googlegroups.com...
On May 16, 3:09 pm, karthick <karthick...@gmail.com> wrote:

We are using SPARTAN 3 E FPGA. I would like to know what is the
difference between ISE 8.2i and ISE 9.2i with respect to the micro
blaze core.
We are able to access the FLASH and RTC via SPI in 8.2i whereas the
same is not possible in 9.2i.
So we would like to know what is the difference between 8.2i and 9.2i.

The most diffirence is that the new version of MicroBlaze use the
unify PLB46 bus and OPB bus is no longer available, thus your opb
peripherials need to be updated to PLB46.

Best Regards,

Wicky

 

[Symon]

"Jon Elson" <elson@wustl.edu> wrote in message
news:483200F4.3090002@wustl.edu...

the whole thing is synchronous, running at 40 MHz on a Spartan 2E, except
a couple external inputs such as the "inputa" above.

Hi Jon,
That's your problem! You have a one hot state machine with five states. This
is implemented as five flipflops(FF). Your external inputs are asynchronous,
and so if their transitions happen to be close to the clock transition, you
wil have a race condition where the signal can get to one/some FF/s, but not
others.
Try this link http://en.wikipedia.org/wiki/Race_condition
Cheers, Syms.
p.s. For completeness, I should mention there is a difference between race
hazards and metastability. Your circuit can suffer from both, but in your
case the race condition is many orders of magnitude more observable than the
'm' word! See CAF passim!

 

[Joseph H Allen]

They've also released Hardcopy-IV, including serdes and PCI-e. Why bother
with ASICs...

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Andreas Ehliar]

On 2008-05-20, fazulu deen <fazulu.vlsi@gmail.com> wrote:

I would like to know how these statements(for,while,do while) are
implemented as logic design(EDIF and constraints) in FPGA device?? .

Though FOR loop is synthesizable , it is always advised that FOR loops
are not to be used in RTL coding. This is because it consumes lot of
resources (like area etc)whether XST will not optimize it before
targetting to FPGA device???

There is nothing magical with for and while loops in a synthesized
design. The synthesizer will simply unroll the loop for you. If
you know this you should easily be able to tell if a for loop is
applicable in your particular case.

For example, if you would like to write something like this in
Verilog a for loop is very suitable to do it:


// Bit reverse the signal:
always @* begin
foo[0] = bar[63];
foo[1] = bar[62];
foo[2] = bar[61];
// Kind of boring to write this without a for loop...


However, lets say that you have an array with 512 values in a
memory and you want to calculate the sum of all values:

always @* begin
sum = 0
for(i=0; i < 512; i = i + 1) begin
sum = sum + mem;
end
end

This is going to be hugely expensive in terms of hardware to
implement as you will end up with 512 adders and force your
memory to be implemented using flip-flops instead of a blockram.
In this case it is probably a much better idea to write a small
state machine to sum the values. It will take around 512 clock
cycles unless you do something clever like reading several values
at a time, but the footprint will be much more reasonable.

/Andreas

 

[Andreas Ehliar]

On 2008-05-20, fazulu deen <fazulu.vlsi@gmail.com> wrote:

I would like to know how these statements(for,while,do while) are
implemented as logic design(EDIF and constraints) in FPGA device?? .

Though FOR loop is synthesizable , it is always advised that FOR loops
are not to be used in RTL coding. This is because it consumes lot of
resources (like area etc)whether XST will not optimize it before
targetting to FPGA device???

There is nothing magical with for and while loops in a synthesized
design. The synthesizer will simply unroll the loop for you. If
you know this you should easily be able to tell if a for loop is
applicable in your particular case.

For example, if you would like to write something like this in
Verilog a for loop is very suitable to do it:


// Bit reverse the signal:
always @* begin
foo[0] = bar[63];
foo[1] = bar[62];
foo[2] = bar[61];
// Kind of boring to write this without a for loop...


However, lets say that you have an array with 512 values in a
memory and you want to calculate the sum of all values:

always @* begin
sum = 0
for(i=0; i < 512; i = i + 1) begin
sum = sum + mem;
end
end

This is going to be hugely expensive in terms of hardware to
implement as you will end up with 512 adders and force your
memory to be implemented using flip-flops instead of a blockram.
In this case it is probably a much better idea to write a small
state machine to sum the values. It will take around 512 clock
cycles unless you do something clever like reading several values
at a time, but the footprint will be much more reasonable.

/Andreas

 

[Symon]

"Jeff Cunningham" <jcc@sover.net> wrote in message
news:483200e3$0$11170$4d3efbfe@news.sover.net...

Clemens wrote:

A different seed for each power-up would have been nice.

Here's a method I've used for this in the past:

Create a ring oscillator that can be stopped by some other bit. The ring
oscillator drives a 2-bit ripple counter.

Once the FPGA clock starts up, count off say 1 second's worth pulses of
your high speed system clock and then disable the ring oscillator. The
ripple counter will now have your 4-bit random value.

This method relies on slight differences in the ring osc rate due to
heating, etc. to add up over 1 second at startup. You might need to
experiment with adding buffers (and make sure the tools don't remove them)
and such to make sure the ring osc rate is not too high.

-Jeff

Hi Jeff,

I've heard that ring oscillators can phase lock to other clocks on the same
die. What did you find? I came across this link that gives some insights
into the pitfalls.
http://warmcat.com/_wp/

Now, this guy really knows how to do random!
http://inventgeek.com/Projects/alpharad/overview.aspx

Cheers, Syms.

 

[Andreas Ehliar]

On 2008-05-20, Kolja Sulimma <ksulimma@googlemail.com> wrote:

Don't confuse architecture and coding.
The parallel linear adder chain will cost exactly the same hardware
when coded with or without the for loop.

Of course, and I believe I wrote in my original post that a for
loop will simply be unrolled. My example was merely meant to
illustrate that it is very easy to write a for loop which will
be extremely expensive in hardware even though it is only a couple
of lines of code. This is why we recommend students to avoid
for-loops in our introductory courses, it is too easy to try to
program instead of designing hardware. If you don't use a for loop
you will immediately figure out that something is not right with
your design as you are going to write 512 individual additions...

However, since you seem to have some experience with synthesizers
that support wait statements I have a question for you: How should
you implement a synchronous reset if you have a process like the
following?

always begin

always @(posedge clk);
// This is the state I want to end up with at reset time
bar <= 0;

always @(posedge clk);
bar <= bar + 1;

always @(posedge clk);
bar <= bar + 1;

always @(posedge clk);
bar <= bar + 1;
end


/Andreas