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 145250

Article: 145250
Subject: Re: What is the most area efficient CRC method
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Wed, 03 Feb 2010 16:13:57 +0100
Links: << >>  << T >>  << A >>
"dlopez" <d@n_o_s_p_a_m.designgame.ca> writes:

> If I want to save area, is it better to use a CRC that works byte
> per byte or bit per bit?

Per bit as it is simply a shift register with xor gates at the
polynomial positions.


Here is a sample program to symbolically convert a serial form to a
parallel form:

http://tinyurl.com/ygvenaz

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: 145251
Subject: Re: Help Please - Xilinx message
From: Daku <dakupoto@gmail.com>
Date: Wed, 3 Feb 2010 08:02:57 -0800 (PST)
Links: << >>  << T >>  << A >>
Dear Sir/Madam,
The code that I posted is actually a task in a large
Verilog module. This large module was simulated
separately with ModelSim 6.5c and open-source
Icarus Verilog 0.9.1. In both cases, the simulation
results were as I had expected them to be.

It was only after these two simulations were run, code
modified and re-run a number of times that I tried this
synthesis with Xilinx ISE 11.1. Unfortunately, when I
tried the whole design, Xilinx gave a 'out of memory'
error at the end, forcing me to divide the module into sub-modules.

Indeed, the 'outtail' is a typo, but I had already corrected
and tried synthesis before the original post. I fully agree
with what you say, but for some reason that I do not
understand, Xilinx's XST thinks this is an empty module.

Thank you.

On Feb 3, 11:09 am, Muzaffer Kal <k...@dspia.com> wrote:
> On Mon, 1 Feb 2010 21:28:38 -0800 (PST), Daku <dakup...@gmail.com>
> wrote:
>
> ...
>
> Before you try to synthesize anything, you should first simulat what
> you wrote (or what a tool generated for you?) Your module has no
> outputs (but a port named outtail, typo?) so all  logic (including
> your clock signal) will be removed. If you put this module in a
> testbench and try to get to what ever it's calculating you will figure
> this out very quickly.
>
> Also the coding style of the module is quite error-prone. Invest some
> time in learning how to write synthesizable rtl for the time you'll
> actually do synthesis so  that you won't have to revise all your code
> after you think you're done typing.
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>
> http://www.dspia.com


Article: 145252
Subject: Re: Help Please - Xilinx message
From: Gabor <gabor@alacron.com>
Date: Wed, 3 Feb 2010 08:16:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 11:02=A0am, Daku <dakup...@gmail.com> wrote:
> Dear Sir/Madam,
> The code that I posted is actually a task in a large
> Verilog module. This large module was simulated
> separately with ModelSim 6.5c and open-source
> Icarus Verilog 0.9.1. In both cases, the simulation
> results were as I had expected them to be.
>
> It was only after these two simulations were run, code
> modified and re-run a number of times that I tried this
> synthesis with Xilinx ISE 11.1. Unfortunately, when I
> tried the whole design, Xilinx gave a 'out of memory'
> error at the end, forcing me to divide the module into sub-modules.
>
> Indeed, the 'outtail' is a typo, but I had already corrected
> and tried synthesis before the original post. I fully agree
> with what you say, but for some reason that I do not
> understand, Xilinx's XST thinks this is an empty module.
>
> Thank you.
>
> On Feb 3, 11:09 am, Muzaffer Kal <k...@dspia.com> wrote:
>
> > On Mon, 1 Feb 2010 21:28:38 -0800 (PST), Daku <dakup...@gmail.com>
> > wrote:
>
> > ...
>
> > Before you try to synthesize anything, you should first simulat what
> > you wrote (or what a tool generated for you?) Your module has no
> > outputs (but a port named outtail, typo?) so all =A0logic (including
> > your clock signal) will be removed. If you put this module in a
> > testbench and try to get to what ever it's calculating you will figure
> > this out very quickly.
>
> > Also the coding style of the module is quite error-prone. Invest some
> > time in learning how to write synthesizable rtl for the time you'll
> > actually do synthesis so =A0that you won't have to revise all your code
> > after you think you're done typing.
> > --
> > Muzaffer Kal
>
> > DSPIA INC.
> > ASIC/FPGA Design Services
>
> >http://www.dspia.com
>
>

Maybe if you post the corrected code as rejected by Xilinx
someone can comment on it.  I don't see any assignment made
to the "output" outtail in the code you originally posted.

regards,
Gabor

Article: 145253
Subject: Re: synthesizing a completely empty design for an FPGA to measure
From: saar drimer <saardrimer@gmail.com>
Date: Wed, 3 Feb 2010 08:50:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 5:47=A0pm, EE EE <eengr....@gmail.com> wrote:
> I want to synthesize a completely empty design, no clocks no combo and
> no sequential logic for a xilinx FPGA using ISE.

Would the following satisfy your requirements?

1. open a new design in fpga_editor (chose your part, etc.) and save
it to empty.ncd
2. bitgen empty.ncd

...you then get an "empty" bitstream, empty.bit.

saar.


Article: 145254
Subject: Re: Help Please - Xilinx message
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 3 Feb 2010 12:43:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 1, 9:28=A0pm, Daku <dakup...@gmail.com> wrote:
> Could some Xilinx guru please help ? I have the following module
> synthesized on Xilinix ISE 11.1. I am getting a message at the end of
> synthesis that no clock exists for design - could some please kindly
> explain what it means ?
>
> `timescale 1ns / 1ps
> /////////////////////////////////////////////////////////////////////////=
//=AD///////
> // Company:
> // Engineer:
> //
> // Create Date: =A0 =A000:08:55 02/02/2010
> // Design Name:
> // Module Name: =A0 =A0GetTail
> // Project Name:
> // Target Devices:
> // Tool versions:
> // Description:
> //
> // Dependencies:
> //
> // Revision:
> // Revision 0.01 - File Created
> // Additional Comments:
> //
> /////////////////////////////////////////////////////////////////////////=
//=AD///////
> module GetTail(
> =A0 =A0 input [0:0] clock,
> =A0 =A0 input [0:511] inarr,
> =A0 =A0 input [0:31] inpriority,
> =A0 =A0 input [0:31] intail,
> =A0 =A0 input [0:31] innum,
> =A0 =A0 input [0:31] toppriority,
> =A0 =A0 input [0:31] outtail
> =A0 =A0 );
>
> parameter MAX =3D 512;
> parameter DATA_WIDTH =3D 32;
>
> reg [0 : 31] localtail;
>
> initial
> =A0begin
> =A0 localtail =3D intail;
> =A0end
>
> always @ (posedge clock)
> =A0 if(inpriority =3D=3D 0)
> =A0 =A0begin
> =A0 =A0 =A0 if(innum > 0 =A0&&
> =A0 =A0 =A0 =A0 =A0inarr[localtail] =3D=3D 0 &&
> =A0 =A0 =A0 =A0 =A0inarr[localtail + 1] =3D=3D 1)
> =A0 =A0 =A0 =A0 begin
> =A0 =A0 =A0 =A0 =A0 =A0localtail =3D localtail + 1;
> =A0 =A0 =A0 =A0 end
>
> =A0 =A0 =A0 else if(innum > 0 &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0localtail =3D=3D MAX - 1 &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0inarr[localtail] =3D=3D 0)
> =A0 =A0 =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 =A0 =A0localtail =3D 0;
> =A0 =A0 =A0 =A0 =A0end
> =A0 end
> =A0 else if(inpriority > 0)
> =A0 =A0begin
> =A0 =A0 localtail =3D toppriority;
> =A0 =A0end
>
> endmodule
>
> Any hints, suggestions would be of immense help - thanks in advance.

In your code you wrote:

>  input [0:0] clock,
>  ....
> always @ (posedge clock)

These are not the same thing.  The first usage is a vector with single
bit number of 0 which is expanded as "clock[0]".

Ed McGettigan
--
Xilinx Inc.


Article: 145255
Subject: How good are Actel tools
From: rickman <gnuarm@gmail.com>
Date: Wed, 3 Feb 2010 18:29:14 -0800 (PST)
Links: << >>  << T >>  << A >>
I know Antti has a lot of experience with Actel, so I expect to hear
from him, but I am sure there are others out there with experience of
Actel tools.  A customer of mine has told me that he used Actel for a
project some 4 or 5 years ago and had a problem with the tools that
Actel could not give a fix for.  I don't recall how he worked around
it and I am sure that particular issue has been fixed, but I now have
the impression that the Actel tools are not as good as tools from the
other three.  I seem to recall some significant issues being discussed
here.

Can anyone confirm or dispute it the relative quality of Actel tools?
Am I mistaken about them?

Rick

Article: 145256
Subject: Re: How to Cure Panic Attacks in 24h See Now
From: rickman <gnuarm@gmail.com>
Date: Wed, 3 Feb 2010 18:32:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 4:17=A0pm, Make Money Online <incomeforlife...@gmail.com>
wrote:
> Discover How to Cure Panic Attacks Today:
>
> http://www.how-to-cure-panic-attacks.eoltt.com/
>
> Is Any Of This Experience Familiar To You?
>
> =A0 =A0 * Maybe you found yourself in the hospital's ER because you
> thought you were having a heart attack only to be told later it was
> anxiety?
> =A0 =A0 * Do you ever fear you might stop breathing because your chest
> feels tight and your breathing erratic?
> =A0 =A0 * When you drive do you fear the idea of getting stuck in traffic=
,
> on a bridge or at red lights?
> .....
>
> Do You Feel Any Of The Following Bodily Sensations?
>
> =A0 =A0 * Dizzy spells leading to panic
> =A0 =A0 * Tightness in throat and chest- shortness of breath
> =A0 =A0 * Racing heart with tingle sensations
> =A0 =A0 * Hot flushes followed by waves of anxiety
> .....
>
> http://www.how-to-cure-panic-attacks.eoltt.com/

Is there some irony to this being posted here?  Surely FPGA designers
have no problems that might cause panic attacks!

Rick

Article: 145257
Subject: Re: What is the most area efficient CRC method
From: rickman <gnuarm@gmail.com>
Date: Wed, 3 Feb 2010 18:41:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 10:13=A0am, Petter Gustad <newsmailco...@gustad.com> wrote:
> "dlopez" <d@n_o_s_p_a_m.designgame.ca> writes:
> > If I want to save area, is it better to use a CRC that works byte
> > per byte or bit per bit?
>
> Per bit as it is simply a shift register with xor gates at the
> polynomial positions.
>
> Here is a sample program to symbolically convert a serial form to a
> parallel form:
>
> http://tinyurl.com/ygvenaz

To do a serial CRC calculation requires a state machine to control
it.  A parallel CRC has to perform multiple xors for each bit using
extra logic compared to the bit serial version, the difference
depending on the size of the CRC.  The question is which uses more
logic, a byte parallel CRC generator or the control logic for the
state machine.  Depending on the CRC chosen, I bet it is close to a
wash, but the only way to know for sure is to build both and see.

Article: 145258
Subject: Board layout for FPGA
From: TSMGrizzly <sbattazz@yahoo.co.jp>
Date: Wed, 3 Feb 2010 21:22:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi guys.. I'm getting ready to start working on my first board layout
with a BGA package (FG456). First will be a prototype for sure.
I was just wondering a few things...

Probably the critical part of my design will be interface to a few
asynchronous SRAMs.

In a relatively low speed design (buses at 10-25MHz) do I need to
worry about things like termination and trace length on the RAM buses?
Should I dedicate address/data pins to each chip in a shared memory
space, or is it better to daisy chain them on a bus? (It seems to me
that routing will be a little easier if each chip gets its own
lines..)

If I won't be using the innermost IO pins, can I get away with a 4-
layer design, two signal layers and power/ground?

Looking at a Xilinx app note with a suggested escape route for this
package, they have three signal layers with 5 mil width traces, the
third of which I believe I can do without...
And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as
well as 3.3V for all of my I/O supplies.. should these all be routed
in the dedicated power layer? If the layer is mostly covered a plane,
which voltage is supposed to be the plane? 3.3V?

And lastly, when connecting I/Os, is there any sensible approach? My
tendency is to want to choose the I/Os so that everything lines up
nicely, but I find it to be a hassle in this case, that in Eagle we
have to connect nets in the schematic first and can't back-annotate
from the board.

Anything else I should be worrying about?

Cheers,

Steve

Article: 145259
Subject: Re: What is the most area efficient CRC method
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 03 Feb 2010 23:33:28 -0600
Links: << >>  << T >>  << A >>
In article <1e71b867-02c0-4702-973b-355411c39446@t21g2000vbo.googlegroups.com>,
 rickman <gnuarm@gmail.com> writes:

>To do a serial CRC calculation requires a state machine to control
>it.  A parallel CRC has to perform multiple xors for each bit using
>extra logic compared to the bit serial version, the difference
>depending on the size of the CRC.  The question is which uses more
>logic, a byte parallel CRC generator or the control logic for the
>state machine.  Depending on the CRC chosen, I bet it is close to a
>wash, but the only way to know for sure is to build both and see.

The bit serial CRC has a simple structure.  It can easily run
at a high clock rate.

The parallel CRC turns into an ugly cloud of XORs.  The details
depend upon the polynomial and how many bits you are processing
in parallel.  Expect it to turn into a good test case for the
placer and router.

If the OP doesn't have enough clocks to process things in
bit serial, it might work out better to do 2 bits in parallel
on each of 4 clocks.  I think that needs 4 inputs worst case
so it fits in one layer of LUT.  (I'm rusty on this, but years
ago I spent a lot of time in this area.  I think I've made all
possible screwups while writing software to check things.
There are a lot of wrong possibilities when you consider big
endian vs little endian, shifting right or left or ...)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 145260
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Wed, 3 Feb 2010 23:04:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 12:22=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote:
> Hi guys.. I'm getting ready to start working on my first board layout
> with a BGA package (FG456). First will be a prototype for sure.
> I was just wondering a few things...
>
> Probably the critical part of my design will be interface to a few
> asynchronous SRAMs.
>
> In a relatively low speed design (buses at 10-25MHz) do I need to
> worry about things like termination and trace length on the RAM buses?
> Should I dedicate address/data pins to each chip in a shared memory
> space, or is it better to daisy chain them on a bus? (It seems to me
> that routing will be a little easier if each chip gets its own
> lines..)

You don't say how many SRAM chips.  The first thing to consider in
evaluating SI (Signal Integrity) issues without a simulation is to
compare the length of the traces to the length of the edges of your
signals.  The rule of thumb I have seen is that if the rising/falling
edges of your signals are six times longer than the length of the
trace (round trip) then you don't need to worry with reflections no
matter how many chips are in the path.  All chips will see essentially
the same edges and there will be little ringing.  Using an FPGA, you
can control the edge rates on the address bus.  But on the data bus,
you can't control the edge rate from the SRAM chips.  If it is too
fast (very likely with fast SRAM parts) the data bus will need to be
terminated.  Terminating multipoint busses is nearly impossible and
even a simple two point bi-directional bus is not optimal but can be
done using series termination.

If you have enough I/O pins on your FPGA to use separate data busses
to the SRAMs, you can terminate each bus using a series resistor to
match impedance of the driver to the impedance of the trace.  This
results in a reflection from the receiver, but the receiver sees the
proper transition (since it is the point of reflection) and the
reflection will not be reflected from the driver.  If any other chips
are connected in the middle of this signal, they will see a half
voltage rise followed by a second rise to the full waveform voltage...
not what you want.  But then, if you allow time for reflections to
settle in your timing analysis, you can ignore the SI issues on the
data and address busses and only be concerned about the timing signals
like the Write strobe.  The address has to be stable by the leading
edge of the write strobe and the data has to be stable by the trailing
edge.  On a read, you simply need to allow some extra time for bus
settling before the FPGA clocks the data in.


> If I won't be using the innermost IO pins, can I get away with a 4-
> layer design, two signal layers and power/ground?

Likely, but you will need to consider a number of thing such as your
design rules in the layout.


> Looking at a Xilinx app note with a suggested escape route for this
> package, they have three signal layers with 5 mil width traces, the
> third of which I believe I can do without...
> And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as
> well as 3.3V for all of my I/O supplies.. should these all be routed
> in the dedicated power layer? If the layer is mostly covered a plane,
> which voltage is supposed to be the plane? 3.3V?

Any voltage that will have switching currents on them should have a
power plane to optimally filter out the transients... in other words,
all of them.  What family are you using that requires 2.5 volts as
well as 1.8???  I thought the recent stuff was all at 1.2 volts for
internal logic and the I/O voltage to match your needs.  Are you
planning on using 2.5 volts for I/O or are you looking at an old
family?  Or maybe I'm not remembering correctly???


> And lastly, when connecting I/Os, is there any sensible approach? My
> tendency is to want to choose the I/Os so that everything lines up
> nicely, but I find it to be a hassle in this case, that in Eagle we
> have to connect nets in the schematic first and can't back-annotate
> from the board.

They why use Eagle?  I do my layouts in FreePCB.  It doesn't support
back annotation actually, but I use forward annotation (updates).  I
plan my pin swaps and add them to the schematic, reload the new net
list and then finish up the routes at the FPGA.  It has been a while
since I have done this, so it may be trickier than I am remembering.
I find it very nice to be able to route with minimal vias.  That also
helps to minimize the number of layers needed.


> Anything else I should be worrying about?

If this is your first board layout, leave yourself plenty of time and
do a lot of checking of your work as well as checking the tool.
There's many a slip twixt cup and lip.  I found my first board layout
to be a real education...

Rick

Article: 145261
Subject: Re: Board layout for FPGA
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 04 Feb 2010 09:23:10 +0100
Links: << >>  << T >>  << A >>
On 04/02/2010 08:04, rickman wrote:
> On Feb 4, 12:22 am, TSMGrizzly<sbatt...@yahoo.co.jp>  wrote:
>> Hi guys.. I'm getting ready to start working on my first board layout
>> with a BGA package (FG456). First will be a prototype for sure.
>> I was just wondering a few things...
>>
>> Probably the critical part of my design will be interface to a few
>> asynchronous SRAMs.
>>
>> In a relatively low speed design (buses at 10-25MHz) do I need to
>> worry about things like termination and trace length on the RAM buses?
>> Should I dedicate address/data pins to each chip in a shared memory
>> space, or is it better to daisy chain them on a bus? (It seems to me
>> that routing will be a little easier if each chip gets its own
>> lines..)
>
> You don't say how many SRAM chips.  The first thing to consider in
> evaluating SI (Signal Integrity) issues without a simulation is to
> compare the length of the traces to the length of the edges of your
> signals.  The rule of thumb I have seen is that if the rising/falling
> edges of your signals are six times longer than the length of the
> trace (round trip) then you don't need to worry with reflections no
> matter how many chips are in the path.  All chips will see essentially
> the same edges and there will be little ringing.  Using an FPGA, you
> can control the edge rates on the address bus.  But on the data bus,
> you can't control the edge rate from the SRAM chips.  If it is too
> fast (very likely with fast SRAM parts) the data bus will need to be
> terminated.  Terminating multipoint busses is nearly impossible and
> even a simple two point bi-directional bus is not optimal but can be
> done using series termination.
>

You have a lot more experience at this sort of thing than me, Rick, so 
I'm a little wary of disagreeing with you.  But I'm sure you'll tell me 
if I get something wrong!

I don't see that you have to worry about any termination here.  With 
fast enough signal edges, you can get ringing - but that typically will 
not matter because you don't sample the signals until the ringing has 
subsided.  When the FPGA is driving the signals, you have (as Rick says) 
controllable rise and fall rates to avoid ringing.  If you don't have 
that, you will want to terminate critical signals like the read and 
write strobes (or clock, for synchronous rams) to avoid triggering 
multiple accesses.  But other than that, just make sure the data and 
address lines are stable before the strobes are sent.  For reads, it's 
possible that you will get ringing due to fast edges from the ram chips 
(though that would require very over-spec'ed ram chips far away from the 
FPGA), but you time your read sampling for after the lines have settled.

Ringing can cause a few problems - the overshoot/undershoot can go 
outside the voltage range of the pins on the line, it can cause 
interference for neighbouring signals, you can't read the signal while 
it is ringing, and it can cause big trouble when connected to 
edge-sensitive inputs.  But most of these are not going to be a problem 
in your case, I think.

If you need to access your rams in parallel, you will need multiple data 
buses, and perhaps multiple address and control buses - that depends on 
the application.  But if you just want to access one at a time, I'd put 
them all on the same bus.  Routing between the chips will be easy, and 
you have less lines from the FPGA to worry about.  At the speeds you are 
talking about, you should have no difficulties.

> If you have enough I/O pins on your FPGA to use separate data busses
> to the SRAMs, you can terminate each bus using a series resistor to
> match impedance of the driver to the impedance of the trace.  This
> results in a reflection from the receiver, but the receiver sees the
> proper transition (since it is the point of reflection) and the
> reflection will not be reflected from the driver.  If any other chips
> are connected in the middle of this signal, they will see a half
> voltage rise followed by a second rise to the full waveform voltage...
> not what you want.  But then, if you allow time for reflections to
> settle in your timing analysis, you can ignore the SI issues on the
> data and address busses and only be concerned about the timing signals
> like the Write strobe.  The address has to be stable by the leading
> edge of the write strobe and the data has to be stable by the trailing
> edge.  On a read, you simply need to allow some extra time for bus
> settling before the FPGA clocks the data in.
>
>
>> If I won't be using the innermost IO pins, can I get away with a 4-
>> layer design, two signal layers and power/ground?
>
> Likely, but you will need to consider a number of thing such as your
> design rules in the layout.
>
>
>> Looking at a Xilinx app note with a suggested escape route for this
>> package, they have three signal layers with 5 mil width traces, the
>> third of which I believe I can do without...
>> And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as
>> well as 3.3V for all of my I/O supplies.. should these all be routed
>> in the dedicated power layer? If the layer is mostly covered a plane,
>> which voltage is supposed to be the plane? 3.3V?
>
> Any voltage that will have switching currents on them should have a
> power plane to optimally filter out the transients... in other words,
> all of them.  What family are you using that requires 2.5 volts as
> well as 1.8???  I thought the recent stuff was all at 1.2 volts for
> internal logic and the I/O voltage to match your needs.  Are you
> planning on using 2.5 volts for I/O or are you looking at an old
> family?  Or maybe I'm not remembering correctly???
>

There is a big difference between "optimal" and "good enough".  If the 
design is fairly small and slow, with low currents, then wide traces to 
the power pins and some capacitors is going to be perfectly sufficient - 
there is no need for dedicated power planes for each supply.

>
>> And lastly, when connecting I/Os, is there any sensible approach? My
>> tendency is to want to choose the I/Os so that everything lines up
>> nicely, but I find it to be a hassle in this case, that in Eagle we
>> have to connect nets in the schematic first and can't back-annotate
>> from the board.
>
> They why use Eagle?  I do my layouts in FreePCB.  It doesn't support
> back annotation actually, but I use forward annotation (updates).  I
> plan my pin swaps and add them to the schematic, reload the new net
> list and then finish up the routes at the FPGA.  It has been a while
> since I have done this, so it may be trickier than I am remembering.
> I find it very nice to be able to route with minimal vias.  That also
> helps to minimize the number of layers needed.
>
>
>> Anything else I should be worrying about?
>
> If this is your first board layout, leave yourself plenty of time and
> do a lot of checking of your work as well as checking the tool.
> There's many a slip twixt cup and lip.  I found my first board layout
> to be a real education...
>
> Rick


Article: 145262
Subject: Re: Board layout for FPGA
From: TSMGrizzly <sbattazz@yahoo.co.jp>
Date: Thu, 4 Feb 2010 01:04:33 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks for the input so far, guys!

I will have two SRAM chips and one parallel EEPROM in one memory
space, and one additional RAM chip in a separate memory space so I
know for sure that that one gets its own dedicated address/control/
data lines.
I was just wondering if the signal integrity would be hurt by extra
loading in chaining up the ones that are on the same bus, but I had a
hunch that at these speeds it wouldn't be such a big problem.

And probably I will be using 10ns RAMs (I haven't looked at the rise/
fall times though) and keeping them physically as close as I can get
them to the FPGA.. maybe about a centimeter away, tops.
Looking at this old Digilent Spartan 3 board I have kicking around, I
don't see any termination between the FPGA and the ISSI SRAMs on
there, but each chip has its own address and data lines.. I dunno if
that's good enough to use as an example or not though.

As for the supply voltages, I'll be using a Virtex II, but this is the
first time I have started to think about implementing my own board and
thus needing to worry about power supplies, and I seemed to remember
some of my dev boards in the past having a couple or three different
regulators on board, but I didn't really think much about it. Looking
at the datasheet though, you're right, Rick, it appears that I just
need a single 1.5V supply for core voltage, and 3.3V for VCC_aux and
all of my I/O. I should have checked that and had the numbers right
before asking, sorry about that.
So if I need power planes for both of these voltages, do they each
need their own layer or can I arrange it carefully in one layer?

Thanks again,

Steve

Article: 145263
Subject: Re: Help Please - Xilinx message
From: Daku <dakupoto@gmail.com>
Date: Thu, 4 Feb 2010 01:57:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Dear All,
The solution is really simple. Instead of editing the source file as:
 module GetTail(
    input [0:0] clock,
    input [0:511] inarr,
    input [0:31] inpriority,
    input [0:31] intail,
    input [0:31] innum,
    input [0:31] toppriority,
    input [0:31] outtail
    );
 TO :
 module GetTail(
    input [0:0] clock,
    input [0:511] inarr,
    input [0:31] inpriority,
    input [0:31] intail,
    input [0:31] innum,
    input [0:31] toppriority,
    output [0:31] outtail
    );

Simply create a brand new project with the source code module declared
as:
 module GetTail(
    input [0:0] clock,
    input [0:511] inarr,
    input [0:31] inpriority,
    input [0:31] intail,
    input [0:31] innum,
    input [0:31] toppriority,
    output [0:31] outtail
    );
Synthesis works just fine after that.
Also, in response to one of the poster's queries, declare a
register as:
reg [0 : 31] outtailA;

and before the 'always' have:
assign outtail = outtailA;
Where the register outtailA gets assigned to appropriate
output values inside the 'always @ (posedge clock)' .
Thank you for your insightful comments.

On Feb 4, 1:43 am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> In your code you wrote:
>
> >  input [0:0] clock,
> >  ....
> > always @ (posedge clock)
>
> These are not the same thing.  The first usage is a vector with single
> bit number of 0 which is expanded as "clock[0]".
>
> Ed McGettigan
> --
> Xilinx Inc.


Article: 145264
Subject: Re: Constraining minimum hold times (Xilinx)
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 4 Feb 2010 10:08:59 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
>...
> I'm not clear about your problem exactly.  It looks like your system
> meets the setup time of the FT2232H chip.  The hold time requirement
> is 0, so that is met for sure unless you have clock routing problems.
> If your clock is on the wrong input, there is not much you can do
> about that.  I am pretty sure you will not find a real way to meet a
> half clock time hold and not blow the setup time.  In fact, I don't
> really see where you are headed with this.

While the idea of half a clock hold time at the output was not my brightest,
the question of specifying hold time requirements in general remains.

> BTW, where did you get the 5.24 ns value?  

It's the value form the ds529 datasheet.

> My concern is that the
> calculation of this time is a bit messy requiring you go add more than
> one offset to a base value as determined by the I/O modes.  Did you do
> all of that?

The post layout timing uses this value too (and some adders for IO voltage,
rate and drive)  

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

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

Article: 145265
Subject: Re: Constraining minimum hold times (Xilinx)
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 4 Feb 2010 10:16:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
Brian Davis <brimdavis@aol.com> wrote:
> Uwe Bonnes wrote:
> >
> > Any other ideas?
> >
>  If the FPGA pin driving the FT2232H WR# pin is within your LHCLK
> domain,
> how about making WR# the only FAST output pin, and then enable writes
> on every other clock cycle.

>  This would cut your transfer rate to 30 Mbytes/sec max into the
> fifo, but give you two clocks of setup for the data lines.

Might be an idea. 

> ( I've never used the FT2232H; the data sheet mentions a max transfer
> rate >= 25 MB/s in synchronous mode, and it looks like you have to
> monitor the TXE# line to stall writes if the FT2232H isn't ready. )

I now read 28 MB/sec with an adaptation of Micah Dowty fastftdi.c on the PC
side and a straight forward approach on the FT2232H side, all outputs fast
with high drive and clocked at the posedge with the USBCLK stapped to a
GCLK.

...

>  With a 16.67 ns clock period, starting at the falling edge you'd need
> to
> delay the data outputs at least 8.33 ns ( to meet the hold time ) but
> no
> more than 8.33 + ( 16.67 - 11 )= 14 ns to meet the next clock's setup
> time.
> So you'd need to hold your I/O's switching time to be within a 5.67 ns
> absolute window, whilst using slow I/O's with no DLL in the clock
> tree.

As I wrote in the other posting, this was not the brightest idea. But the
question remains, how to specify external  hold time requirements with ISE.

Bye

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

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

Article: 145266
Subject: Re: synthesizing a completely empty design for an FPGA to measure
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 4 Feb 2010 02:20:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On 29 Jan., 18:50, Antti <antti.luk...@googlemail.com> wrote:
> On Jan 29, 7:47=A0pm, EE EE <eengr....@gmail.com> wrote:

> you do have to have one output or the flow will fail
>
> well, design with no IO's could actually be useful, if all data
> transfer goes over BSCAN, but the tools require one top level port to
> be present

Also, a design with only inputs can be used to use DCI to terminate
external signals
which might be required for external circuitry to work properly.


Kolja Sulimma

Article: 145267
Subject: Re: synthesizing a completely empty design for an FPGA to measure
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 4 Feb 2010 02:22:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On 29 Jan., 20:35, rickman <gnu...@gmail.com> wrote:
> =A0So the tools might just
> require an input, but I doubt it.

This used to be the case a few years ago. The bug has been fixed, but
might have been reintroduces later.
Designs with only outputs did  not work in an earlier ISE version but
I had a real
world application with only a single output. (An CPLD had to hold OE
of a flash at constant high,
in a later version there would be logic added to the CPLD, but that
was not read yet)
Translate failed with the error mesage similar to: Does not fit, your
design has 0 inputs but
the CPLD you have chosen has only 32 Pins.

I opened a web case to research a design that will provide a constant
output without the tool
optimizing away the dummy input.
You could not synthesize
output <=3D '1';
in that version.

Kolja Sulimma




Article: 145268
Subject: Re: Board layout for FPGA
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 4 Feb 2010 10:24:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
TSMGrizzly <sbattazz@yahoo.co.jp> wrote:
...
> And lastly, when connecting I/Os, is there any sensible approach? My
> tendency is to want to choose the I/Os so that everything lines up
> nicely, but I find it to be a hassle in this case, that in Eagle we
> have to connect nets in the schematic first and can't back-annotate
> from the board.

Perhaps the net2ucf.pl Perl script I just uploaded to CADSOFT can help you
to generate LOC cobnstrains from an eagle netlist.

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

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

Article: 145269
Subject: Re: Board layout for FPGA
From: Symon <symon_brewer@hotmail.com>
Date: Thu, 04 Feb 2010 10:28:42 +0000
Links: << >>  << T >>  << A >>
On 2/4/2010 8:23 AM, David Brown wrote:
>
> You have a lot more experience at this sort of thing than me, Rick, so
> I'm a little wary of disagreeing with you. But I'm sure you'll tell me
> if I get something wrong!
>
> I don't see that you have to worry about any termination here. With fast
> enough signal edges, you can get ringing - but that typically will not
> matter because you don't sample the signals until the ringing has
> subsided.
>
> Ringing can cause a few problems - the overshoot/undershoot can go
> outside the voltage range of the pins on the line, it can cause
> interference for neighbouring signals, you can't read the signal while
> it is ringing, and it can cause big trouble when connected to
> edge-sensitive inputs. But most of these are not going to be a problem
> in your case, I think.
>

Dear David, Steve,

Going "outside the voltage range of the pins on the line" can break the 
device. IIRC there are Xilinx appnotes which go into this problem in 
some detail; powering 3.3V with 3V was something I think they suggested! 
(See XAPP653)
Also, the thing will probably fail any sort on electromagnetic 
compliance test that you would need to do before you sell this. And you 
are unlikely to be able to listen to 'The Archers' while this thing is 
in the room.


To the OP, in the absence of micro-vias, I would recommend a 6 layer 
board. Maybe like this:-

signal
signal
ground
ground
power/signal
signal

Keep all the layers as close together as your PCB manufacturer allows 
and make up the board thickness with the core between the two ground 
layers. Xilinx on the top. Route the powers, or use copper pours. Try to 
make room for bypass caps on the back of the board from the FPGA. This 
stack up will make it very difficult for a beginner to go wrong from an 
SI point of view, as ground is always near. This is particularly true if 
you have a nice spread of ground vias tying the two ground planes 
together. That doesn't mean you shouldn't simulate it with Hyperlynx, 
but I bet that won't happen! Always examine your ground plane pair at 
the end of the routing process to make sure you haven't cut any big 
slots in it with string of vias.

Finally, _real_ engineers use DRAMs! ;-)

HTH., Syms.

p.s. Did I make it clear that the ground is important?

Article: 145270
Subject: Re: Board layout for FPGA
From: TSMGrizzly <sbattazz@yahoo.co.jp>
Date: Thu, 4 Feb 2010 02:57:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 7:28=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 2/4/2010 8:23 AM, David Brown wrote:
>
>
>
>
>
> > You have a lot more experience at this sort of thing than me, Rick, so
> > I'm a little wary of disagreeing with you. But I'm sure you'll tell me
> > if I get something wrong!
>
> > I don't see that you have to worry about any termination here. With fas=
t
> > enough signal edges, you can get ringing - but that typically will not
> > matter because you don't sample the signals until the ringing has
> > subsided.
>
> > Ringing can cause a few problems - the overshoot/undershoot can go
> > outside the voltage range of the pins on the line, it can cause
> > interference for neighbouring signals, you can't read the signal while
> > it is ringing, and it can cause big trouble when connected to
> > edge-sensitive inputs. But most of these are not going to be a problem
> > in your case, I think.
>
> Dear David, Steve,
>
> Going "outside the voltage range of the pins on the line" can break the
> device. IIRC there are Xilinx appnotes which go into this problem in
> some detail; powering 3.3V with 3V was something I think they suggested!
> (See XAPP653)
> Also, the thing will probably fail any sort on electromagnetic
> compliance test that you would need to do before you sell this. And you
> are unlikely to be able to listen to 'The Archers' while this thing is
> in the room.
>
> To the OP, in the absence of micro-vias, I would recommend a 6 layer
> board. Maybe like this:-
>
> signal
> signal
> ground
> ground
> power/signal
> signal
>
> Keep all the layers as close together as your PCB manufacturer allows
> and make up the board thickness with the core between the two ground
> layers. Xilinx on the top. Route the powers, or use copper pours. Try to
> make room for bypass caps on the back of the board from the FPGA. This
> stack up will make it very difficult for a beginner to go wrong from an
> SI point of view, as ground is always near. This is particularly true if
> you have a nice spread of ground vias tying the two ground planes
> together. That doesn't mean you shouldn't simulate it with Hyperlynx,
> but I bet that won't happen! Always examine your ground plane pair at
> the end of the routing process to make sure you haven't cut any big
> slots in it with string of vias.
>
> Finally, _real_ engineers use DRAMs! ;-)
>
> HTH., Syms.
>
> p.s. Did I make it clear that the ground is important?

Thanks all, for the good information! This will definitely help.

Uwe, I'll take a look at your script, that seems like it could be very
handy!

Symon, DRAM is out of the question in this design, gotta stick with
SRAM.. and it isn't really for sale, it's a custom one-off thing so I
don't think I have to worry about compliance tests.

I was hoping to keep the cost down a little by skimping on the layers
but I'm sure I can afford to go with six layers just fine.. six is
what I initially told the boss would probably be happening, I was just
wondering if I could get away with four.

Steve

Article: 145271
Subject: Re: How good are Actel tools
From: whygee <yg@yg.yg>
Date: Thu, 04 Feb 2010 12:01:27 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> Can anyone confirm or dispute it the relative quality of Actel tools?
> Am I mistaken about them?

I am speaking only about my own personal point of view of mine...
and under Windows (have not yet had time to re-try under Fedora)

The Actel tools take a while to get used too,
like most big SW suites. It's its own world...
It is not particularly terrible, I can do
mostly what I want, inside the bounds of reality
and the target chip's capacity.

I have not tried to "hack" things because I don't
want to be dependent on a specific too, I do my stuff
in VHDL and add a constraint file (which can be a bitch
is a few situations but not a real limit).
The latest version of Libero seems OK,
it's not groundbreaking but I sense some care
for user friendliness (which is a whole different
concept in itself if the FPGA world ;-D)

When badly blocked, I could contact my local FAE
and even a local Actel office. The usefulness of
the  online reporting/case tool is ... mitigated
but can be tried if a project is badly screwed.

Oh, and comp.arch.fpga is very helpful too ;-)

So I can say that "Actel works for my case" and
I'm fine with it. It just takes a lot of time
to get used to the rules and design of this particular "world",
so it's usual to ask impossible or difficult things
when learning. Later, one does design things around
the chip's capabilities instead of the contrary,
and it goes smoothly (after a few iterations ;-D)

I'm curious to read other people's impressions...

> Rick
yg

-- 
http://ygdes.com / http://yasep.org

Article: 145272
Subject: Re: Board layout for FPGA
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.gmail.com>
Date: Thu, 04 Feb 2010 05:08:25 -0600
Links: << >>  << T >>  << A >>
>Thanks for the input so far, guys!
>
>I will have two SRAM chips and one parallel EEPROM in one memory
>space, and one additional RAM chip in a separate memory space so I
>know for sure that that one gets its own dedicated address/control/
>data lines.
>I was just wondering if the signal integrity would be hurt by extra
>loading in chaining up the ones that are on the same bus, but I had a
>hunch that at these speeds it wouldn't be such a big problem.
>

I suggest checking the data bus turn-off (->Z) time of the EEPROM. It might
be rather long, meaning that an EEPROM read followed by an SRAM access
causes data corruption.

If it is too long, either put an extra buffer with fast turn-off on the
board, or else use dedicated data signals and mux it in the FPGA.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145273
Subject: Re: synthesizing a completely empty design for an FPGA to measure
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 4 Feb 2010 03:10:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On 30 Jan., 09:59, Antti <antti.luk...@googlemail.com> wrote:

> there is no need to test anything with empty design :)

I just prepared a golden empty reference netlist and volunteer to
perform
a manual equivalence check on your emtpy netlist for 50$.

Kolja

Article: 145274
Subject: Re: Matching hadware and software CRC
From: whygee <yg@yg.yg>
Date: Thu, 04 Feb 2010 12:32:35 +0100
Links: << >>  << T >>  << A >>
dlopez wrote:
> Hi,
> There seems to be an endless numbers of way to mess up CRC calculations!
yes :-)

> Has anyone come up with the right way to match a software calculated CRC
> with whay comes out of either the 'easics' core or the 'outputlogic' core
> (both yielding the same result in simulation).
write your own HDL code.

> Here are questions:
> -should I reverse or inverse the input data? What order?
> -should I reverse or inverse the output data? What order?
are you using a Galois or Fibonacci configuration ? :-D
that makes 8 combinations, maybe you should try them all ?
when correctly done (automated), it does not take much time.

> I'm using
> CRC-32: 0x04C11DB7  =  x32 + x26 +  x23 + x22 + x16 + x12 +                
>              x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1

ok, CRC32 in bit-serial configuration is easy, simple and fast,
you need about 32 bits of bit-shifting storage with about 15 XOR2 (or 5 LUT4).


have you read http://www.ross.net/crc/download/crc_v3.txt ?
it is HIGHLY recommended and easy to read.

> Thanks
good luck,
CRCs can be disturbing at first but it's not that difficult in the end.

> Diego
yg
-- 
http://ygdes.com / http://yasep.org



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