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 153175

Article: 153175
Subject: Re: Verilog module in VHDL project - ISE 13
From: Gabor <gabor@szakacs.invalid>
Date: Tue, 03 Jan 2012 08:35:06 -0500
Links: << >>  << T >>  << A >>
Mike Harrison wrote:
> I want to use the Xilinx Spartan-6 XAPP495 HDMI/DVI transmit/receive modules, which are written in
> Verilog,  in a new VHDL project, as I'm much more familiar with VHDL - I don't do enough FPGA stuff
> to justify the time to learn a new language for one project.
> 
> Can anyone point me towards how I can  include the verilog modules and make the signals visible to
> my VHDL - any example of a verilog module included in a VHDL project would probably give me enough
> to go on.
> 

The simplest way is using the ISE NAvigator GUI.  Add the verilog source
file to the project.  Then highlight the file in the Hierarchy window
(clik once) and in the design process window you should see "View HDL
instantiation template."  In a VHDL project, the template should default
to VHDL, but if for some reason it shows up in Verilog, you can change
the properties for "View HDL Instantiation Template" by right clicking
and there is a drop-down menu to select the language.

The VHDL template will contain the entity declaration as well as
an instantiation template.

-- Gabor

Article: 153176
Subject: Re: Clock distribution for ADC and jitter
From: Andy <jonesandy@comcast.net>
Date: Tue, 3 Jan 2012 12:18:51 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21 2011, 3:07=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> This is all true, but the question is jitter. =A0If you only have one ADC=
,
> then skew isn't usually a problem. =A0Jitter can be.

The OP stated he had 2 ADCs. Skew can be a problem with 2 ADCs,
depending upon the application.

Andy

Article: 153177
Subject: slimming down ISE install
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 04 Jan 2012 11:02:56 +0000
Links: << >>  << T >>  << A >>
Just installed ISE webpack 13.3 on my laptop and things are getting a bit tight space-wise - a lot
of space (several gb) appears to be used by files for device families I'll never use, but removing
the dirs makes the software bork. 

There's presumably a file/dir list somewhere telling it what to look for - has anyone figured out
where this is ? 

Removing the EDK dir is the only thing I've found so far that appears not to break anything

Article: 153178
Subject: Re: slimming down ISE install
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 04 Jan 2012 14:06:42 +0100
Links: << >>  << T >>  << A >>
Mike Harrison wrote:
> Just installed ISE webpack 13.3 on my laptop and things are getting a bit tight space-wise - a lot
> of space (several gb) appears to be used by files for device families I'll never use, but removing
> the dirs makes the software bork. 
> 
> There's presumably a file/dir list somewhere telling it what to look for - has anyone figured out
> where this is ? 
> 
> Removing the EDK dir is the only thing I've found so far that appears not to break anything

If you spend more than an hour for slimming down the installation, it is
cheaper to buy an external hard disk.

-- 
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Article: 153179
Subject: Re: slimming down ISE install
From: Mittens <mittens@_nospam_hush.ai>
Date: Wed, 04 Jan 2012 14:05:28 -0000
Links: << >>  << T >>  << A >>
On Wed, 04 Jan 2012 13:06:42 -0000, Frank Buss <fb@frank-buss.de> wrote:

> If you spend more than an hour for slimming down the installation, it is
> cheaper to buy an external hard disk.

Agreed. I have both ISE and Quartus installed on a 16G pen drive. Under  
Linux I just bind it to /opt and everything's happy. Surprisingly it  
doesn't seem to hurt performance noticeably either.

Article: 153180
Subject: Re: slimming down ISE install
From: Laust Brock-Nannestad <lbn@prg.dtu.dk.invalid>
Date: 04 Jan 2012 14:38:39 GMT
Links: << >>  << T >>  << A >>

Mike Harrison <mike@whitewing.co.uk> wrote:

> Just installed ISE webpack 13.3 on my laptop and things are getting a
> bit tight space-wise - a lot of space (several gb) appears to be
> used by files for device families I'll never use, but removing the
> dirs makes the software bork. 

On the all-too-small SSD in my laptop, I have enabled the built-in
transparent folder compression in Windows for the Xilinx folder. This
reduces the size of the ISE 10.1 (old, I know) installation from 9.4GB
to 5.6GB. I expect something similar could be done on Linux.

I didn't measure the impact on performance, but since synthesis and P&R
are mainly CPU intensive, not disk I/O intensive, I've assumed it is not
significant.


Regards,

Laust

Article: 153181
Subject: Trying to select a development board, can somebody help me make an
From: chthon <jurgen.defurne@gmail.com>
Date: Wed, 4 Jan 2012 10:52:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

I am trying to decide what board to order for a project I want to do betwee=
n April and June in school, and for other projects, mainly to exercise VHDL=
 and design interesting projects. The school project itself is the design o=
f a general purpose DSP data path.

I have currently staked out the following boards, based upon the features I=
 need and the price.

Digilent   | Atlys          |
Enterpoint | Drigmorn-3     |
Xilinx     | 3A Starter kit |
Enterpoint | Drigmorn-2     |
Xilinx     | 3E Starter kit |

However, also delivery time and ease of ordering are somewhat necessary, an=
d three of the five boards come from the US, while 2 come from the UK, and =
I live in Belgium.

On the other hand, the Drigmorn boards do not feature a video output (whate=
ver type), which is also something I would like to have.

And then there is the choice of FPGA:

                 LX16   XC3S700A
Logic cells:     14579  13248
Slices     :     2278   5888
Block RAM  :     576    360
Distributed RAM: 136    92

Since a LX16 seems to have less slices than a XC3S700A, does that mean that=
 the LX16 will reach its maximum earlier than the XC3S700A? Conversely, doe=
s the lesser amount of distributed RAM on the XC3S700A mean that it could b=
e that in a pipelined design it has less possibilities than the LX16?

I must say, that if I have to select purely on price, this would certainly =
favor the Drigmorn-2, but does the choice of the XC3S700A FPGA in that case=
 limit me in my design choices?

And another point, I only own a MacBook Air anymore, with Linux on Virtualb=
ox and ISE inside it, but how does this translate in my choices for program=
ming the selected board?

Regards,

Jurgen Defurne

Article: 153182
Subject: Beginner question on FIFO in "FPGA prototyping by VHDL examples"
From: Bill <bfmackin@nospam.mchsi.com>
Date: Wed, 04 Jan 2012 15:09:47 -0600
Links: << >>  << T >>  << A >>
I am very new to FPGA programming.  I'm using "FPGA Prototyping by
VHDL examples" to learn VHDL.  I've gotten up to section 4.5.3 FIFO
buffer, and am having trouble understanding what might happen in the
code...

In the 'register file' section, array_reg(w_ptr_reg) is set to w_data.

In the fifo control section, w_ptr_reg is set to w_ptr_next.

Both events happen when clk'event and clk='1'.


Is there any guarantee as to which one happens first?  How do I know
whether array_reg(???) will use w_ptr_reg as the index, or w_ptr_next?


If there is anyone who is working through this same book, I'd like to
start an email correspondence.

Bill

Article: 153183
Subject: Re: Beginner question on FIFO in "FPGA prototyping by VHDL examples"
From: gtwrek@sonic.net (Mark Curry)
Date: 04 Jan 2012 21:53:34 GMT
Links: << >>  << T >>  << A >>
In article <8lf9g7dq02hfn7lmf5cnmjm4atidskuqte@4ax.com>,
Bill  <bfmackin@nospam.mchsi.com> wrote:
>I am very new to FPGA programming.  I'm using "FPGA Prototyping by
>VHDL examples" to learn VHDL.  I've gotten up to section 4.5.3 FIFO
>buffer, and am having trouble understanding what might happen in the
>code...
>
>In the 'register file' section, array_reg(w_ptr_reg) is set to w_data.
>
>In the fifo control section, w_ptr_reg is set to w_ptr_next.
>
>Both events happen when clk'event and clk='1'.
>
>
>Is there any guarantee as to which one happens first?  How do I know
>whether array_reg(???) will use w_ptr_reg as the index, or w_ptr_next?
>

Well, I don't have the book, so I'm giving this advice blind - but - 
you're not thinking hardware.  What hardware does the VHDL represent?

There's no "first" in the above - they're happening at the same time - at
the postive edge of a clk.

Draw out what you think the hardware will look like.  Sketch a few
timing diagrams.  Under what timing conditions will things work
as intended?

>If there is anyone who is working through this same book, I'd like to
>start an email correspondence.

Just use this thread, so others can contribute too. 

Regards,

Mark



Article: 153184
Subject: Re: Beginner question on FIFO in "FPGA prototyping by VHDL examples"
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 4 Jan 2012 22:30:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mark Curry <gtwrek@sonic.net> wrote:
> In article <8lf9g7dq02hfn7lmf5cnmjm4atidskuqte@4ax.com>,
> Bill  <bfmackin@nospam.mchsi.com> wrote:
>>I am very new to FPGA programming.  I'm using "FPGA Prototyping by
>>VHDL examples" to learn VHDL.  I've gotten up to section 4.5.3 FIFO
>>buffer, and am having trouble understanding what might happen in the
>>code...

(snip)
>>Both events happen when clk'event and clk='1'.

>>Is there any guarantee as to which one happens first?  How do I know
>>whether array_reg(???) will use w_ptr_reg as the index, or w_ptr_next?

> Well, I don't have the book, so I'm giving this advice blind - but - 
> you're not thinking hardware.  What hardware does the VHDL represent?

> There's no "first" in the above - they're happening at the same time - at
> the postive edge of a clk.

Also, note that the FIFO is usually built from a dual-port RAM,
so that it can write a new entry and read an old one at the same time.

Since you didn't mention it, I presume your FIFO doesn't have separate
read and write clocks, though that is also allowed.  

-- glen

Article: 153185
Subject: Re: Beginner question on FIFO in "FPGA prototyping by VHDL examples"
From: Andy <jonesandy@comcast.net>
Date: Wed, 4 Jan 2012 16:07:12 -0800 (PST)
Links: << >>  << T >>  << A >>
Don't confuse execution order with simulation time. Seqential
statements execute in sequential order, one after the other, without
consuming any simulation time (except a wait statement). Simulation
time only advances while the process is suspended (e.g. waiting for
the next clock edge, whether explicitly executing a wait statement, or
implicitly at the bottom of a process that has a sensitvity list).

If w_ptr_reg is a signal, its value is not actually updated until (in
execution order) the process suspends (to wait for another clock). So,
references to a signal, whether they occur before or after (in
execution order, not simulation time) the assignment to it, return the
non-updated value. This is different from how software code works in
typical programming languages.

If w_ptr_reg is a variable, it works just like software; the variable
is updated immediately upon execution of the assignment statement (or
procedure call, if it is an out or inout parameter). So references to
a variable occurring before (in execution order) the assignment will
return the non-updated value, but references to the variable occuring
after (in execution order) the assignment will return the updated
value.

Whether you use variables or signals, the synthesis tool will create
hardware (i.e. gates and registers) that mimics the simulation
behavior of the code. Whether that hardware is fits in the device or
meets timing constraints is a different issue. I find it works best
for me if I focus on coding the correct behavior, then worry about
what hardware it generates if it does not fit or meet timing. Of
course, with experience comes the knowledge of what types of behavior
take too much resources or won't meet timing! Because of my preference
and experience, I use more variables, saving signals for only inter-
process communications.

Andy

Article: 153186
Subject: Re: Beginner question on FIFO in "FPGA prototyping by VHDL examples"
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 5 Jan 2012 00:44:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
Andy <jonesandy@comcast.net> wrote:

> Don't confuse execution order with simulation time. Seqential
> statements execute in sequential order, one after the other, without
> consuming any simulation time (except a wait statement). Simulation
> time only advances while the process is suspended (e.g. waiting for
> the next clock edge, whether explicitly executing a wait statement, or
> implicitly at the bottom of a process that has a sensitvity list).

This is all true, but with a FIFO things get much more interesting.

Consider that the write data could come just before, at the same time
as (more likely in simulation than actual practice) or just after
the read cycle. The FIFO has to handle all three cases.  
(If the FIFO is empty, you shouldn't even try reading, and if full
you shouldn't write.) 

Some immediately pass data written to an empty FIFO to the output,
others don't.

> If w_ptr_reg is a signal, its value is not actually updated until (in
> execution order) the process suspends (to wait for another clock). So,
> references to a signal, whether they occur before or after (in
> execution order, not simulation time) the assignment to it, return the
> non-updated value. This is different from how software code works in
> typical programming languages.

I usually write mostly structural verilog (module references and 
continuous assignment) but sometimes behavioral.  When I do write
behavioral verilog, I try to order the statements such that the
result is the same as if they were executed sequentially.

(snip)
> Whether you use variables or signals, the synthesis tool will create
> hardware (i.e. gates and registers) that mimics the simulation
> behavior of the code. Whether that hardware is fits in the device or
> meets timing constraints is a different issue. I find it works best
> for me if I focus on coding the correct behavior, then worry about
> what hardware it generates if it does not fit or meet timing. Of
> course, with experience comes the knowledge of what types of behavior
> take too much resources or won't meet timing! Because of my preference
> and experience, I use more variables, saving signals for only inter-
> process communications.

Well, real hardware timing may result in hardware that works and a
simulation that doesn't, if you aren't careful with the way you
write the statements.  

-- glen

Article: 153187
Subject: Re: Beginner question on FIFO in "FPGA prototyping by VHDL examples"
From: Andy <jonesandy@comcast.net>
Date: Thu, 5 Jan 2012 08:10:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 4, 6:44=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Andy <jonesa...@comcast.net> wrote:
> > Don't confuse execution order with simulation time. Seqential
> > statements execute in sequential order, one after the other, without
> > consuming any simulation time (except a wait statement). Simulation
> > time only advances while the process is suspended (e.g. waiting for
> > the next clock edge, whether explicitly executing a wait statement, or
> > implicitly at the bottom of a process that has a sensitvity list).
>
> This is all true, but with a FIFO things get much more interesting.
>
> Consider that the write data could come just before, at the same time
> as (more likely in simulation than actual practice) or just after
> the read cycle. The FIFO has to handle all three cases.
> (If the FIFO is empty, you shouldn't even try reading, and if full
> you shouldn't write.)
>
> Some immediately pass data written to an empty FIFO to the output,
> others don't.
>
> > If w_ptr_reg is a signal, its value is not actually updated until (in
> > execution order) the process suspends (to wait for another clock). So,
> > references to a signal, whether they occur before or after (in
> > execution order, not simulation time) the assignment to it, return the
> > non-updated value. This is different from how software code works in
> > typical programming languages.
>
> I usually write mostly structural verilog (module references and
> continuous assignment) but sometimes behavioral. =A0When I do write
> behavioral verilog, I try to order the statements such that the
> result is the same as if they were executed sequentially.
>
> (snip)
>
> > Whether you use variables or signals, the synthesis tool will create
> > hardware (i.e. gates and registers) that mimics the simulation
> > behavior of the code. Whether that hardware is fits in the device or
> > meets timing constraints is a different issue. I find it works best
> > for me if I focus on coding the correct behavior, then worry about
> > what hardware it generates if it does not fit or meet timing. Of
> > course, with experience comes the knowledge of what types of behavior
> > take too much resources or won't meet timing! Because of my preference
> > and experience, I use more variables, saving signals for only inter-
> > process communications.
>
> Well, real hardware timing may result in hardware that works and a
> simulation that doesn't, if you aren't careful with the way you
> write the statements.
>
> -- glen

I missed an important detail. The OP does not mention whether both
assignment and reference are in the same process (I assumed they
were). If the signal assignment is in one process, another process
(clocked on the same edge of same clock signal) referencing the same
signal will not see the updated value until the next clock edge. All
VHDL processes scheduled to run in the same delta cycle must suspend
before any of their driven signals are updated. If two or more
processes are both sensitive to the same clock signal, then they will
run in the same delta cycle. The issues of (non-shared) variables'
update semantics affecting inter-process communication is completely
avoided in VHDL, by not allowing (non-shared) variables to be accessed
by multiple processes in the first place. Verilog's semantic parallel
to VHDL's signal/variable is the non-blocking/blocking assignment.
Unfortunately, verilog simulators are perfectly happy running code
that performs blocking assignments and accesses in different
"processes" (always blocks), even though the behavior is undefined/
erratic. This makes using these features riskier in Verilog (unless
you have a good linting tool, which is a must with Verilog, IMHO).

Things to look for if simulation behavior differs from the hardware:
Synthesis reported warnings/errors,
Static timing analysis (STA) reported warnings/errors,
Delta delay issues on clock signals (usually caused by assigning one
clock signal from another, then moving data between processes clocked
by both),
Incorrectly defined multi-cycle or false path constraints (and not
running full-timing simulations to verify them)
Testbench issues (incorrectly representing actual HW interface
counterparts),
Synthesis or simulator bug,
... there are probably others.

In VHDL, with regard to variables, signals and orders of assignments
and references, the behavior of synchronous processes (and therefore
of the synthesized HW) is very well defined by the LRM, making
differences in their behavior (excepting the above) extremely rare in
my experience.

Andy

Article: 153188
Subject: Re: Beginner question on FIFO in
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 05 Jan 2012 10:40:08 -0600
Links: << >>  << T >>  << A >>
>I am very new to FPGA programming.  I'm using "FPGA Prototyping by
>VHDL examples" to learn VHDL.  I've gotten up to section 4.5.3 FIFO
>buffer, and am having trouble understanding what might happen in the
>code...

[elided]

In real-world usage for Xilinx FPGAs, you do not write code that will be
synthesized into a FIFo. You use their CoreGen tool to generate a FIFO
block, and instantiate that into the controlling logic.

However, what others have already said about the essentially simultaneous
nature of hardware versus the sequential programming paradigm holds true.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153189
Subject: Re: Beginner question on FIFO in
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 05 Jan 2012 11:30:45 -0600
Links: << >>  << T >>  << A >>
On Thu, 05 Jan 2012 10:40:08 -0600, RCIngham wrote:

>>I am very new to FPGA programming.  I'm using "FPGA Prototyping by VHDL
>>examples" to learn VHDL.  I've gotten up to section 4.5.3 FIFO buffer,
>>and am having trouble understanding what might happen in the code...
> 
> [elided]
> 
> In real-world usage for Xilinx FPGAs, you do not write code that will be
> synthesized into a FIFo. You use their CoreGen tool to generate a FIFO
> block, and instantiate that into the controlling logic.

Actually, in what passes for the real world here, I find a description 
that makes the Xilinx tools make an effective use of FPGA resources.

This has more to do with my personal strong anti-"wizard" bias, and a 
desire to write portable HDL.  I suspect that if writing HDL took up a 
bigger proportion of my professional life than the 2% or so that it does, 
that my attitude might differ.

> However, what others have already said about the essentially
> simultaneous nature of hardware versus the sequential programming
> paradigm holds true.
	   
Yes.  When you write software you should be thinking in the back of your 
mind what the processor will be doing (and possibly what the compiler's 
optimizer will do, first).  When you write Verilog or VHDL you should be 
thinking in the back of your mind what logic will be generated.  I have 
to admit that when I do this most of the blocks have "74HCxx" on them, 
but you still want to devote part of your brain to thinking what actual 
hardware will get used: it keeps you from doing really stupid things.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 153190
Subject: Re: Trying to select a development board, can somebody help me make
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 05 Jan 2012 22:18:50 +0100
Links: << >>  << T >>  << A >>
chthon wrote:
> I am trying to decide what board to order for a project I want to do between April and June in school, and for other projects, mainly to exercise VHDL and design interesting projects. The school project itself is the design of a general purpose DSP data path.
> 
> I have currently staked out the following boards, based upon the features I need and the price.
> 
> Digilent   | Atlys          |
> Enterpoint | Drigmorn-3     |
> Xilinx     | 3A Starter kit |
> Enterpoint | Drigmorn-2     |
> Xilinx     | 3E Starter kit |

I have the 3E starter kit and it is nice, but depends on what you need.
It is from Xilinx, so it works with your ISE installation (if USB works
from within your VM installation, but should be no problem). The
advantage is that it has many peripheral components intergrated on the
board and a VGA connector.

But if you need e.g. just 16 colors, you could easily build your own VGA
output with a R2R network (that's what they are using on the starter kit
anyway), or attach a LCD display, and then you could buy a cheaper kit,
like this nice one:

http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=593

This uses a Cyclone FPGA from Altera. I have this, too, and it is
awesome. I think for beginners the Quartus IDE is easier than the Xilinx
IDE, especially the MegaWizard is nice.

-- 
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Article: 153191
Subject: Re: Trying to select a development board, can somebody help me make
From: Joel Williams <nospamwhydontyoublogaboutit@nospamgmail.com>
Date: Fri, 06 Jan 2012 13:10:05 +1030
Links: << >>  << T >>  << A >>
 > Since a LX16 seems to have less slices than a XC3S700A, does that
 > mean that the LX16 will reach its maximum earlier than the XC3S700A?
 > Conversely, does the lesser amount of distributed RAM on the XC3S700A
 > mean that it could be that in a pipelined design it has less
 > possibilities than the LX16?

The Spartan-6 has a different architecture to the Spartan-3*, so it's a 
little tricky to compare them directly using some of these numbers. If 
you have an existing design, you can try implementing it on the two and 
see how well it maps to either architecture.

In general, the Spartan-6 is newer and better, and adds some hardware 
(PLL, SERDES), which may or may not be useful to you.

 > On the other hand, the Drigmorn boards do not feature a video output
 > (whatever type), which is also something I would like to have.

As Frank said, a VGA output port can be quite easy to add on. If you're 
interested in HDMI/DVI, it will be a lot easier to buy a board that 
includes this facility.

Personally, I've found that while not the cheapest board by a long shot, 
the Digilent ATLYS currently offers the best value for money (at least 
in the Xilinx space) if you qualify for the academic discount as it 
includes quite a large chip (XC6SLX45), DDR2, gigabit Ethernet, four 
HDMI ports (two input, two output), and high speed I/O. I've written 
some notes on the board here: http://tristesse.org/DigilentAtlysResources

I've also compiled a list of cheap development boards: 
http://tristesse.org/CheapFPGADevelopmentBoards

> And another point, I only own a MacBook Air anymore, with Linux on Virtualbox and ISE inside it, but how does this translate in my choices for programming the selected board?

I use ISE through Windows on Parallels Desktop and there are no problems 
whatsoever. Make sure you use one the supported Linux distributions (and 
a supported version of that distribution - this will not necessarily be 
the latest!) and you shouldn't have too much trouble with ISE.

Some non-Xilinx boards use their own JTAG adapter and proprietary 
software, so make sure a Linux/Mac version is available. Alternatively, 
you can get a Xilinx Platform Cable USB II (or something that pretends 
to be one) and you should have no trouble using Xilinx iMPACT directly.

Joel


Article: 153192
Subject: Handling overflow in a self-repeating frequency counter
From: Philip Pemberton <philpem@philpem.me.uk>
Date: 06 Jan 2012 02:49:54 GMT
Links: << >>  << T >>  << A >>
Hi guys.

I'm currently working on the HDL code for an open-source project which 
images 'strange and unusual' magnetic media (mainly floppy discs but also 
MFM and RLL hard disc drives).

To do this, I measure the time between incoming pulses on the RD_DATA 
line. One pulse indicates a magnetic transition. The time between a given 
pair of pulses encodes (in a roundabout way) a data bit. This is a gross 
oversimplification, but serves the purpose for this explanation.

After measuring the time between two pulses, it re-arms and measures 
between the second pulse and the one following it. Rinse, repeat.

The captured timing values are stored in an on-FPGA FIFO buffer, then 
passed onto an off-chip Cypress 100MHz 512K*8bit high speed static RAM 
(this thing needs A LOT of storage). The period counter's reference clock 
is 100MHz. 10 nanoseconds per count. The most significant bit is reserved 
for a 'flag' bit (it's used by other parts of the design), leaving a 
range of 0 to 127 for the counter.

The problem is, a lot of the timing values are about 800 counts long. To 
work around this, I implemented logic to store a 'special' value in the 
stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8 
bits, all zeroes.

This raises a problem: if any two incoming pulses are measured at exactly 
128 clocks apart (or a modulo thereof), the HDL stores a carry (0x00)... 
immediately followed by the value of the counter, which is 0x00 (because 
the count of clock pulses is a multiple of 128). This is messing up the 
datastream, and I only caught it because a friend mentioned it, I added a 
test case to the testbench, and I got a truckload of assertion failures.

The Verilog code is here:
  http://hg.discferret.com/microcode/file/1b4ea3919380/DiscReader.v
  http://hg.discferret.com/microcode/file/1b4ea3919380/
Flag_Delay1tcy_OneCycle.v
  (other modules are here if you need them: http://hg.discferret.com/
microcode/file/1b4ea3919380 )

I have also rewritten DiscReader.v to use a free-running counter (which 
seems like a better solution) -- that version is here:
  http://pastebin.com/evMtjXWj

Feel free to offer comments on either of these... the rewrite is later 
code, and as far as I can tell fully synchronous to the clock (the older 
code has some other corner cases -- hence the rewrite).


Effectively the byte-stream format is:
CARRY starts at 0.
  0x00 or 0x80 -- add 128 to CARRY.
  Anything else -- the timing value is CARRY + (this_byte AND 0x7F). 
Clear CARRY to zero afterwards.


The best idea I've come up with thus far is to scrap the overflow logic, 
cause the acquisition to abort with an error state if the timer 
overflows, and use a 12-bit or larger counter (which would allow for a 
maximum count of 40us). This would of course mean I'd have to rewrite the 
RAM controller logic to handle a 16-bit stream and chunk it into 
bytes... :(


Can anyone think of a good way to resolve this, ideally without 
introducing timing jitter (although the acquisition clock is PLL'd off a 
20MHz TTL oscillator, so there's probably a bit of that already)? I'm not 
overly attached to the bitstream format, so feel free to propose changes.


Thanks,
-- 
Phil.
philpem@philpem.me.uk
http://www.philpem.me.uk/

Article: 153193
Subject: Re: Handling overflow in a self-repeating frequency counter
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 6 Jan 2012 03:18:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
Philip Pemberton <philpem@philpem.me.uk> wrote:

> I'm currently working on the HDL code for an open-source project which 
> images 'strange and unusual' magnetic media (mainly floppy discs but also 
> MFM and RLL hard disc drives).

> To do this, I measure the time between incoming pulses on the RD_DATA 
> line. One pulse indicates a magnetic transition. The time between a given 
> pair of pulses encodes (in a roundabout way) a data bit. This is a gross 
> oversimplification, but serves the purpose for this explanation.

> After measuring the time between two pulses, it re-arms and measures 
> between the second pulse and the one following it. Rinse, repeat.

> The captured timing values are stored in an on-FPGA FIFO buffer, then 
> passed onto an off-chip Cypress 100MHz 512K*8bit high speed static RAM 
> (this thing needs A LOT of storage). The period counter's reference clock 
> is 100MHz. 10 nanoseconds per count. The most significant bit is reserved 
> for a 'flag' bit (it's used by other parts of the design), leaving a 
> range of 0 to 127 for the counter.

The bit rate for floppies is 125000b/s at the low end, and, as far as
I know, 1000000b/s at the high end.  To decode FM or MFM data, you
don't need a hugh amount of resolution.  There are only two different
times between transitions, at least ideally.

The GCR code used by older Apple formats has more different times, but
not all that many, and the bit rate is on the low side.

To write a floppy from data, you need to consider precompensation,
which needs a little finer timing.  Note that writing a floppy from
your data stream, you will also need to consider precompensation.

Anyway, my suggestion is to use a slower clock.  Then it should only
overflow at splice points, or other places where the data doesn't
matter.

> The problem is, a lot of the timing values are about 800 counts long. To 
> work around this, I implemented logic to store a 'special' value in the 
> stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8 
> bits, all zeroes.

The design of codes that can be uniquely decoded is well known.
One answer is to store one more than the overflow value.  
That is, a 128 count should be X'0001', so X'00' always means overflow,
and never data.  X'007f' then will be 254, and X'000001' will be 255.

The logic is a little more complicated, but shouldn't be hard to
fit into an FPGA.

-- glen

Article: 153194
Subject: voltage drop on STRATIX FPGA supply planes
From: "colin_toogood@yahoo.com" <colin_toogood@yahoo.com>
Date: Fri, 6 Jan 2012 01:55:03 -0800 (PST)
Links: << >>  << T >>  << A >>
Guys

I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
plane. It is showing a 30mV voltage drop across the BGA itself, let
alone getting the power to the BGA which is dropping another 50mV.

Surely the 30mV cannot be true as there is a power plane in the BGA
package itself.

Historically I would look at the size of the plane and assume that
everything is fine and I can't help wondering whether this worst case
analysis is a bit pointless.

Any opinions?

BTW I'm already just beyond the PCB thickness I'm allowed so I can't
just use thicker copper.

Colin

PS. sorry about using Google, I'm sitting in the UK behind a firewall
controlled by an Indian call centre.

Article: 153195
Subject: Re: Handling overflow in a self-repeating frequency counter
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 6 Jan 2012 11:17:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Fri, 06 Jan 2012 02:49:54 +0000, Philip Pemberton wrote:

> Hi guys.
> 
> I'm currently working on the HDL code for an open-source project which
> images 'strange and unusual' magnetic media (mainly floppy discs but
> also MFM and RLL hard disc drives).
> 
> To do this, I measure the time between incoming pulses on the RD_DATA
> line. One pulse indicates a magnetic transition. The time between a
> given pair of pulses encodes (in a roundabout way) a data bit. 
...

> The problem is, a lot of the timing values are about 800 counts long. To
> work around this, I implemented logic to store a 'special' value in the
> stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8
> bits, all zeroes.

Consider A-law (or mu-law) encoding instead.

- Brian

Article: 153196
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: Bill Sloman <bill.sloman@ieee.org>
Date: Fri, 6 Jan 2012 05:15:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 6, 10:55=A0am, "colin_toog...@yahoo.com"
<colin_toog...@yahoo.com> wrote:
> Guys
>
> I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
> plane. It is showing a 30mV voltage drop across the BGA itself, let
> alone getting the power to the BGA which is dropping another 50mV.
>
> Surely the 30mV cannot be true as there is a power plane in the BGA
> package itself.

Power planes have a finite resistance per square, and logic frequently
slurps up a lot of current. One of the joys of mixed signal design is
trying to stop digital supply current from returning through the
ground connections used to define an analog ground.

<snip>

--
Bill Sloman, Nijmegen


Article: 153197
Subject: Re: Handling overflow in a self-repeating frequency counter
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 6 Jan 2012 13:45:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
Brian Drummond <brian@shapes.demon.co.uk> wrote:
> On Fri, 06 Jan 2012 02:49:54 +0000, Philip Pemberton wrote:

>> I'm currently working on the HDL code for an open-source project which
>> images 'strange and unusual' magnetic media (mainly floppy discs but
>> also MFM and RLL hard disc drives).
 
>> To do this, I measure the time between incoming pulses on the RD_DATA
>> line. One pulse indicates a magnetic transition. The time between a
>> given pair of pulses encodes (in a roundabout way) a data bit. 

>> The problem is, a lot of the timing values are about 800 counts long. To
>> work around this, I implemented logic to store a 'special' value in the
>> stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8
>> bits, all zeroes.

> Consider A-law (or mu-law) encoding instead.

That should work.  I think, though, that it doesn't matter much.

The gaps between sectors, and between the before/after the index address
mark, all have data bits in them as formatted.  

The problem comes with write splice.  (Put "write splice" floppy into
google, and some hits will be for floppy controllers.  At least the
one for the 279x describes the track format.)

Each sector has a header with the track/sector/side/length bytes.
When writing, the controller finds the header for the appropriate
sector, counts off a specific number of bytes (different for FM and
MFM), then turns on the write current.  It then writes some binary
zeros, an address mark, followed by the data, CRC, a few more bytes,
then turns the write current off.  The point where it turns on and
off is the write splice, and I believe that is where you see the
long counts.  The exact length doesn't matter much, and will vary
between drives, and with the motor speed, with a tolerance of maybe
about 10%.  

The gap after the sector and before the next sector header is long
enough such that within tolerance the write splice won't overwrite
the next header.  The gaps are generously large (but with data bits
in them) to allow for a variation in motor speeds and controller
clocks.  (Much more motor speed than clock.)

There are enough data bits after the write splice and before the
address mark to sync up the PLL.  

What is the variation in length for these long counts, and about
how many do you find on a track?

I presume you start reading on the index pulse, and stop at the
next index pulse.  If you want to convert a track image back to
a floppy, you will start writing at the index pulse, and either stop
at the next (if you don't run out of data), or continue writing
binary zeros (in FM or MFM form) until the index pulse.

-- glen

Article: 153198
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: Allan Herriman <allanherriman@hotmail.com>
Date: 06 Jan 2012 13:53:05 GMT
Links: << >>  << T >>  << A >>
On Fri, 06 Jan 2012 01:55:03 -0800, colin_toogood@yahoo.com wrote:

> Guys
> 
> I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
> plane. It is showing a 30mV voltage drop across the BGA itself, let
> alone getting the power to the BGA which is dropping another 50mV.
> 
> Surely the 30mV cannot be true as there is a power plane in the BGA
> package itself.
> 
> Historically I would look at the size of the plane and assume that
> everything is fine and I can't help wondering whether this worst case
> analysis is a bit pointless.
> 
> Any opinions?
> 
> BTW I'm already just beyond the PCB thickness I'm allowed so I can't
> just use thicker copper.


I've had this issue in recent designs too.  Currents are higher, voltages 
are lower (1.0, 0.9V, etc), supply tolerances are tighter (3% instead of 
5% now for some parts) but copper doesn't seem conduct any better :(

About the only thing that's improving is the DC/DC converter; some parts 
have a reference precision better than 1% now.  Transient response is 
also better due to faster switching frequencies and cheap, large, low ESR 
caps.


The Cu in the BGA is thin.  I don't know its sheet resistance, but it's 
probably greater than the (roughly) 1mohm / square of the inner layers of 
your PCB.  At 20 or 30 amperes, you don't need many squares to get a 
voltage drop that puts you outside the supply voltage tolerance of the 
FPGA.

In my last "high power" FPGA design, we ended up with a plane on an inner 
(1/2 oz) layer in parallel with a fill on an outer (1oz) layer for the 
core supply.  The layout guy hated doing it, but it gave adequate results.

It might also be possible to use smaller vias in your BGA fanout to 
reduce the "swiss cheese" effect on your planes, but I haven't tried that 
in an actual design.

I've noticed that some PC motherboard manufacturers are advertising 2oz 
copper as a feature, so it's not just FPGA folk that are feeling the pain.

Regards,
Allan

Article: 153199
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: Allan Herriman <allanherriman@hotmail.com>
Date: 06 Jan 2012 15:07:31 GMT
Links: << >>  << T >>  << A >>
On Fri, 06 Jan 2012 13:53:05 +0000, Allan Herriman wrote:

> On Fri, 06 Jan 2012 01:55:03 -0800, colin_toogood@yahoo.com wrote:
> 
>> Guys
>> 
>> I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
>> plane. It is showing a 30mV voltage drop across the BGA itself, let
>> alone getting the power to the BGA which is dropping another 50mV.
>> 
>> Surely the 30mV cannot be true as there is a power plane in the BGA
>> package itself.
>> 
>> Historically I would look at the size of the plane and assume that
>> everything is fine and I can't help wondering whether this worst case
>> analysis is a bit pointless.
>> 
>> Any opinions?
>> 
>> BTW I'm already just beyond the PCB thickness I'm allowed so I can't
>> just use thicker copper.
> 
> 
> I've had this issue in recent designs too.  Currents are higher,
> voltages are lower (1.0, 0.9V, etc), supply tolerances are tighter (3%
> instead of 5% now for some parts) but copper doesn't seem conduct any
> better :(
> 
> About the only thing that's improving is the DC/DC converter; some parts
> have a reference precision better than 1% now.  Transient response is
> also better due to faster switching frequencies and cheap, large, low
> ESR caps.
> 
> 
> The Cu in the BGA is thin.  I don't know its sheet resistance, but it's
> probably greater than the (roughly) 1mohm / square of the inner layers
> of your PCB.  At 20 or 30 amperes, you don't need many squares to get a
> voltage drop that puts you outside the supply voltage tolerance of the
> FPGA.
> 
> In my last "high power" FPGA design, we ended up with a plane on an
> inner (1/2 oz) layer in parallel with a fill on an outer (1oz) layer for
> the core supply.  The layout guy hated doing it, but it gave adequate
> results.
> 
> It might also be possible to use smaller vias in your BGA fanout to
> reduce the "swiss cheese" effect on your planes, but I haven't tried
> that in an actual design.
> 
> I've noticed that some PC motherboard manufacturers are advertising 2oz
> copper as a feature, so it's not just FPGA folk that are feeling the
> pain.


Another thing I've been doing is to boost the nominal voltage slightly.

(Contrived) example:  Requirement is 0.9V +/- 3% (i.e. +/- 27mV) at the 
die.

I budget +/- 1% (+/- 9mV) for the transient response.
I budget +/- 1% (+/- 9mV) for the initial tolerance.

This leaves +/- 1% (+/- 9mV) for the voltage drop.  However, the voltage 
drop is only in the -ve direction.  If I change the feedback resistors to 
move the nominal voltage up by +1% (+ 9mV), I can allow for a voltage 
drop of 0 to -2% (0 to -18mV).

Of course, one can use remote sense on the DC/DC converter to get 
feedback to eliminate the voltage drop.  My experience has been that the 
degradation of the transient response (due to having a more phase shift 
in the feedback) isn't worth it.  YMMV.

Regards,
Allan



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