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 145475

Article: 145475
Subject: Re: using an FPGA to emulate a vintage computer
From: jmfbahciv <jmfbahciv@aol>
Date: Thu, 11 Feb 2010 09:27:23 -0500
Links: << >>  << T >>  << A >>
Rick wrote:
> On Feb 10, 2:55 am, Olafur Gunnlaugsson <o...@audiotools.com> wrote:
>> Žann 05/02/2010 18:19, Eric Chomko skrifaši:
>>
>>> Has anyone created a copy machine of an old system using an FPGA? I
>>> was wondering if it would be possible to take an entire SWTPC 6800 and
>>> compile the schematics and have it run on an FPGA board.? Wouldn't
>>> even have to be the latest Xylinx product, I suspect.
>> There are loads of such projects out there, even a commercial one called
>> C-One "the reconfigurable computer", here:http://www.c64upgra.de/c-one/
> 
> It is a great effort but last time I checked it was a bit pricey ~$300
> for a basic system.
> 
Just out of curiosity, how old are you?  Giving the decade is OK.
A game system is that price so I'm wondering if "kids" think $300
is too much.

/BAH

Article: 145476
Subject: Re: using an FPGA to emulate a vintage computer
From: james <bubba@bud.u>
Date: Thu, 11 Feb 2010 11:01:39 -0500
Links: << >>  << T >>  << A >>
On Wed, 10 Feb 2010 11:06:30 -0800 (PST), Rick
<richardcortese@gmail.com> wrote:

|It is a great effort but last time I checked it was a bit pricey ~$300
|for a basic system.
|
|===================

Try 333 euros now. $453 US. That includes the Cyclone 3 FPGA extender
board. 

james

Article: 145477
Subject: Re: Multple architectures in ISE top level module?
From: "tamoruso" <tamo4567@gmail.com>
Date: Thu, 11 Feb 2010 10:29:58 -0600
Links: << >>  << T >>  << A >>
ISE drives me crazy!

One of the most powerful features of VHDL is the ability to handle 
multiple architectures and configurations for the same entity.  This 
makes for efficient simulation, regression testing, and promotes code 
reuse.  

I've spent way too many hours trying to figure out problems with 
ISE synthesis (XST).  I have tried various permutations of 
configurations, separate files for each configuration, using just 
a single configuration file in the project, all to no avail.  The 
GUI always seems to display the incorrect architecture.  Now, I 
"think" this is just a GUI anomaly and in actuality the tool 
knows which architecture bind.  But, when you need to use the GUI 
to help diagnose a synthesis problem how do you trust it?  The only
thing you can do is let it rip the use the (terrible) schematic RTL
viewer to get a sense of what it did.  This is not efficient if you
tend to have a heavily scripted development flow.  Who wants to look
at the RTL view for every regression?


Same files, same configuration used with Synplicity and everything
is great!  I always know what architecture it is going to use, and 
(get this) I can select which top-level configuration to synthesize!  
However many times Synplicity has difficulty closing timing or I can't 
check-out a license because someone else has it tied up (but that's 
rant for a later time).  Plus, Synplicity is expensive compared to 
ISE (OK, you get what you pay for).
 

It's one thing to be frustrated because I cannot get a design to 
synthesize with XST.  It's another problem altogether when it 
synthesizes incorrectly!  I spent a lot of time debugging why some
logic was getting optimized away.  Turns out XST did not use the 
architecture it was instructed to use at a lower level in the design.

Bottom line:  
Xilinx cannot handle VHDL configuration constructs properly. So until 
it does, I will have to overcome my loathing to dumb-down my code and
scripts in order to accommodate Xilinx. 
 

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145478
Subject: Re: using an FPGA to emulate a vintage computer
From: james <bubba@bud.u>
Date: Thu, 11 Feb 2010 11:33:46 -0500
Links: << >>  << T >>  << A >>
On Thu, 11 Feb 2010 09:27:23 -0500, jmfbahciv <jmfbahciv@aol> wrote:

|Rick wrote:
|> On Feb 10, 2:55 am, Olafur Gunnlaugsson <o...@audiotools.com> wrote:
|>> Žann 05/02/2010 18:19, Eric Chomko skrifaši:
|>>
|>>> Has anyone created a copy machine of an old system using an FPGA? I
|>>> was wondering if it would be possible to take an entire SWTPC 6800 and
|>>> compile the schematics and have it run on an FPGA board.? Wouldn't
|>>> even have to be the latest Xylinx product, I suspect.
|>> There are loads of such projects out there, even a commercial one called
|>> C-One "the reconfigurable computer", here:http://www.c64upgra.de/c-one/
|> 
|> It is a great effort but last time I checked it was a bit pricey ~$300
|> for a basic system.
|> 
|Just out of curiosity, how old are you?  Giving the decade is OK.
|A game system is that price so I'm wondering if "kids" think $300
|is too much.
|
|/BAH
|===========

Kids today have little concept of what is too much. 

For what the board does it is a good price even now at 333 euros. The
boards are no longer shipping at the 269 euros anymore. The increase
price now reflects that the system ships with the FPGA extender card.
Also the main board uses two older FPGAs, EP1K30 and EP1K100.  

You also need a SVGA monitor, a keyboard, memory, a PS2 style mouse,
floppy drives, hard drive, ATX case and ATX power supply. So to get a
system up and minimally running is going to cost you at least another
$200 additionally unless you have all those components lieing around
in your juck box. 

It is a great effort on the team's part. It can be very flexible
system now with the Cyclone 3 extender board. 

james  

Article: 145479
Subject: Re: Multple architectures in ISE top level module?
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.gmail.com>
Date: Thu, 11 Feb 2010 10:58:42 -0600
Links: << >>  << T >>  << A >>
<snip>

>Bottom line:  
>Xilinx cannot handle VHDL configuration constructs properly. So until 
>it does, I will have to overcome my loathing to dumb-down my code and
>scripts in order to accommodate Xilinx. 
> 

The Design Manager GUI isn't clever in the way it handles conditional
generates, either. Thus I haven't told it the whereabouts of the file
containing the behavioural model of one of the sub-modules that mostly I
use when simulating, in case XST tries to synthesize it!

My experience is that synthesis tools are less smart with regards to
generates and configurations than simulators (ModelSim, at least).
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145480
Subject: Re: using an FPGA to emulate a vintage computer
From: Rick <richardcortese@gmail.com>
Date: Thu, 11 Feb 2010 09:52:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 11, 6:27=A0am, jmfbahciv <jmfbahciv@aol> wrote:
> Rick wrote:
> > On Feb 10, 2:55 am, Olafur Gunnlaugsson <o...@audiotools.com> wrote:
> >> =DEann 05/02/2010 18:19, Eric Chomko skrifa=F0i:
>
> >>> Has anyone created a copy machine of an old system using an FPGA? I
> >>> was wondering if it would be possible to take an entire SWTPC 6800 an=
d
> >>> compile the schematics and have it run on an FPGA board.? Wouldn't
> >>> even have to be the latest Xylinx product, I suspect.
> >> There are loads of such projects out there, even a commercial one call=
ed
> >> C-One "the reconfigurable computer", here:http://www.c64upgra.de/c-one=
/
>
> > It is a great effort but last time I checked it was a bit pricey ~$300
> > for a basic system.
>
> Just out of curiosity, how old are you? =A0Giving the decade is OK.
> A game system is that price so I'm wondering if "kids" think $300
> is too much.
>
> /BAH

59. Directed at Olafur too, it isn't a question of value for goods
delivered. Having recently priced getting some prototype boards made,
I think they are priced appropriately.

I have a pretty good idea of ratio of shall we say sophisticated users
to the Plebs. An analogy would be a Porsche is more expensive then
riding a bus. The Plebs aren't concerned with file I/O, clock
frequency, or storage. If they look back at all it is just to play a
game of Pac Man or Bard's Tale. An emulator or SoC is fine and suited
to their needs. This reduces the potiential market to hard core users.

Rick


Article: 145481
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Thu, 11 Feb 2010 19:05:11 +0100
Links: << >>  << T >>  << A >>
Brian Davis wrote:

>  Unless a hypothetical assembly house stuffed, say, a 1.2 ohm
> (1R2) where a one Kohm (102) NPN base resistor was supposed
> to go, lighting the DONE LED just fine but clamping the DONE
> voltage seen at the FPGA pin to one VBE drop such that the
> FPGA thinks DONE never went high.
Ha, THAT was it! Thank you, you made my day! Putting in the right value
fixes the issue: Bit-files load without the DONE_cycle-setting, plus
indirect SPI-programming works now.

The only question that remains is: why doesn't iMPACT give a "DONE did
not go high"-message? If it did, I'd probably gotten there sooner.

And another question is: what else did the assembly house mess up on
this board? Lot of 0402 bird seed on this one, no way to tell by looking
at it... But at least all supply voltages are correct and so on.

>  It is a major nuisance that Xilinx doesn't provide the JTAG-SPI
> core for iMPACT in either source or black-box synthesizable form.
Yep. Antti did post his version of such a core in the Xilinx user
forums, though:

http://tinyurl.com/yjtharz

This is a start as well.

>  This forces customers to reinvent the indirect SPI FLASH wheel.
> 
>  If you ever need to do this, I'd suggest starting with either the
> Ken Chapman Picoblaze flash example (S3E) or the Avnet V5 SPI
> flash eval board example, which demonstrates the V5 logic needed
> to do user access to the internal configuration logic.
Fortunately, in the "production" release it'll be simpler. A host PC
will send SPI-commands which will just be passed through the FPGA basically.

The indirect programming bit is just something I wanted to try since
I've never used it before and was a bit puzzled when it didn't work.

BTW, Xilinx' xapp1020 can come in handy, too:

http://tinyurl.com/y955nom

>  Also of note, command line 10.1 PROMGEN has an undocumented-in-
> the-manuals " -spi " option that will let you generate an .mcs
> file for SPI proms with the proper bit order.
Good to know. Did I mention the iMPACT GUI sucks? :)

Thanks for all the excellent pointers! Learned quite a bit from this.

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

Article: 145482
Subject: Re: 10 layer stack for 1152 pin BGA routing (and decoupling)?
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 Feb 2010 11:14:13 -0800 (PST)
Links: << >>  << T >>  << A >>
My "religion" does not tell you how to make a stackup without more
information.

Do you need to set specific impedance on any traces?  If so, what
values, number of traces and approximate length.

Do you expect any EMI issues?  What is your fastest edge rate?

The way you have your stack set up seems to be optimized for
controlling trace impedance by having a gnd/pwr layer immediately
adjacent to each signal layer.  The stackup below will give you a
stackup optimized for power distribution and still allow for impedance
control if you can adjust your trace width to suit.  I assume you have
read the arguments pro and con the significance of inter plane
capacitance.  With the stackup below, you can still get good impedance
control on the outer layers with slightly wider traces.  But you won't
be routing too many signals on the outer layers if your board is at
all dense, the components eat up al the routing space.  It will be
important on *all* layers to minimize routing of signals one above the
other on adjacent layers to prevent coupling and crosstalk.  The easy
remedy is to route orthogonally on adjacent layers.  It also provides
a good means of getting signals around the board with minimal vias
which is important.

 1  signal - Top
 2  signal
 3  GND plane  -- >=3D 5 mil to PWR plane 4
 4  PWR plane
 5  signal
 6  signal
 7  GND plane  -- >=3D 5 mil to PWR plane 8
 8  PWR plane
 9  signal
10  signal - Bottom

With ten layers the average thickness (using 1/2 oz copper) is about 6
mil.  You will likely make it a little thicker between layers 4, 5, 6
and 7 since that is stripline rather than microstrip.  You will want
to use very thin layers between 3 & 4 and 7 & 8 to maximize PDS
capacitance.

If you want to go for maximum signal isolation from crosstalk, I would
isolate all signal layers with power and ground.

 1  signal - Top
 2  GND plane
 3  signal
 4  PWR plane
 5  signal
 6  signal
 7  GND plane
 8  signal
 9  PWR plane
10  signal - Bottom

Well, I guess 5 and 6 are still adjacent, but you can't have
everything...  This arrangement does lend itself to ground pours on
all signal layers other than 5 and 6.  If you use ground pours on
layers 5 and 6 it will much with the impedance control because of the
routing on the adjacent signal layer.

This is just a seat-of-the-pants analysis.  If you need impedance
control on all layers, you would need to analyze each signal layer in
terms of impedance vs. trace width.  You may find that your approach
is better for your specific needs.

Can you explain the rational behind your stackup?  I don't want to
argue about it, I just want to learn what you are thinking.


On Feb 11, 5:05=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> I'm about to start the layout on a board which I think needs
> a 10 laye-r stack.
>
> After the religious wars betwen rickman and Symon on decoupling I'm
> unsure on the best stack but am veering towards...
>
> 1 =A0signal - Top
> 2 =A0GND plane
> 3 =A0signal
> 4 =A0signal
> 5 =A0PWR plane
> 6 =A0GND plane
> 7 =A0signal
> 8 =A0signal
> 9 =A0PWR & GND plane
> 10 signal - Bottom
>
> There will almost definitely be power pours on layer 9, the BGA
> will be on the top layer.
>
> Comments?

I wouldn't bother mixing ground and power on one layer.  Even with a
couple of signal layers between, you will get significant capacitance
between the power and ground.  Since the power layers act as ground
for high frequency signals you don't need the ground on layer 9 unless
it is for connectivity.  Are you expecting gnd layers 6 and 2 to be
chopped up?  With two power layers they will be much less chopped up
if you have more than two power voltages.

Rick

Article: 145483
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: vanepp@sfu.ca (Peter Van Epp)
Date: Thu, 11 Feb 2010 19:50:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
<snip>
>And another question is: what else did the assembly house mess up on
>this board? Lot of 0402 bird seed on this one, no way to tell by looking
>at it... But at least all supply voltages are correct and so on.
<snip>

	This reminded me of an article I saw in Circuit Cellar on Smart Tweezers
(http://www.smarttweezers.com) which might help you out. I expect there may 
be some problems in circuit with parallel paths though, I think it is more
meant for identifying mystery components in isolation.

Peter Van Epp

Article: 145484
Subject: Synplify out of memory
From: Ben Gelb <ben.gelb@gmail.com>
Date: Thu, 11 Feb 2010 11:52:11 -0800 (PST)
Links: << >>  << T >>  << A >>
I have a really large lookup table (members of a finite field) encoded
as a function. This function is only ever invoked with a constant
argument, so it shouldn't actually be synthesized. Altera's synthesis
tool seems to handle this with no problem.

When I try to use Synplify to synthesize my design (particularly this
constant function), the verilog compiler (c_ver) runs out of memory
(hits the 4GB limit).

Seems like Synplify isn't figuring out that the function doesn't
actually need to be synthesized.

So I guess the question is two-fold:

1. is there a better way to encode a large lookup table like that that
should really only be used at elaboration time?
2. is it possible to enable c_ver to run in 64-bit mode, so that it
can go past the 4G boundary?

Thanks,
Ben

Article: 145485
Subject: What is the basis on flip-flops replaced by a latch
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 11 Feb 2010 12:05:58 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
I finally understand the reason when a flip-flops can be replaced by a
latch.

Here is the excerpt from the paper "Atom Processor Core Made FPGA
Synthesizable"
Optimized for a frequency range from 800MHz to 1.86Ghz,
the original Atom design makes extensive use of latches
to support time borrowing along the critical timing paths.
With level-sensitive latches, a signal may have a delay larger
than the clock period and may flush through the latches
without causing incorrect data propagation, whereas the delay
of a signal in designs with edge-triggered flip-flops must
be smaller than the clock period to ensure the correctness of
data propagation across flip-flop stages [3]. It is well known
that the static timing analysis of latch-based pipeline designs
with level-sensitive latches is challenging due to two
salient characteristics of time borrowing [2, 3, 14]: (1) a
delay in one pipeline stage depends on the delays in the previous
pipeline stage. (2) in a pipeline design, not only do
the longest and shortest delays from a primary input to a
primary output need to be propagated through the pipeline
stages, but also the critical probabilities that the delays on
latches violate setup-time and hold-time constraints. Such
high dependency across the pipeline stages makes it very
difficult to gauge the impact of correlations among delay
random variables, especially the correlations resulting from
reconvergent fanouts. Due to this innate difficulty, synthesis
tools like DC-FPGA simply do not support latch analysis
and synthesis correctly."

In short, a pipeline with several FFs can be replaced with a pipeline
with two FFs in the ends and normal latches inserted between them to
steal time slack.

FF1 ---> FF2 ---> FF3 ---> FF4
FF1 ------->l2 --------> l3--> FF4.

I saw the circuits before, but not realized what the basic reason was.
With the above paper, I now know that the technology is not a new, it
originated in 1980s.

Weng


Article: 145486
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: Gabor <gabor@alacron.com>
Date: Thu, 11 Feb 2010 12:35:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 11, 2:50=A0pm, van...@sfu.ca (Peter Van Epp) wrote:
> <snip>>And another question is: what else did the assembly house mess up =
on
> >this board? Lot of 0402 bird seed on this one, no way to tell by looking
> >at it... But at least all supply voltages are correct and so on.
>
> <snip>
>
> =A0 =A0 =A0 =A0 This reminded me of an article I saw in Circuit Cellar on=
 Smart Tweezers
> (http://www.smarttweezers.com) which might help you out. I expect there m=
ay
> be some problems in circuit with parallel paths though, I think it is mor=
e
> meant for identifying mystery components in isolation.
>
> Peter Van Epp

We've got a set of these in our production area here, which is also
the test and rework area (small company).  You can often get
information
in-circuit, especially in cases like this where you might see a much
lower
impedance than you were expecting.  They're also great for comparing
two boards when one doesn't work, since whatever you measure on the
good board (R L or C) is just a relative reference point rather than
the presumed component value.

Regards,
Gabor

Article: 145487
Subject: Re: Synplify out of memory
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 Feb 2010 16:24:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 11, 2:52=A0pm, Ben Gelb <ben.g...@gmail.com> wrote:
> I have a really large lookup table (members of a finite field) encoded
> as a function. This function is only ever invoked with a constant
> argument, so it shouldn't actually be synthesized. Altera's synthesis
> tool seems to handle this with no problem.
>
> When I try to use Synplify to synthesize my design (particularly this
> constant function), the verilog compiler (c_ver) runs out of memory
> (hits the 4GB limit).
>
> Seems like Synplify isn't figuring out that the function doesn't
> actually need to be synthesized.
>
> So I guess the question is two-fold:
>
> 1. is there a better way to encode a large lookup table like that that
> should really only be used at elaboration time?
> 2. is it possible to enable c_ver to run in 64-bit mode, so that it
> can go past the 4G boundary?


When you say the function is only called with a constant argument, is
it truly a constant in terms of the language?  Maybe if you are using
a variable which is initialized to a value and not changed, this is
not so well understood.  Otherwise, I can't think why the entire
function would need to be "implemented" rather than just evaluated.
Which language are you using?

Rick

Article: 145488
Subject: Re: What is the basis on flip-flops replaced by a latch
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 11 Feb 2010 17:33:19 -0800 (PST)
Links: << >>  << T >>  << A >>
Yes, latch-based design is much older than flop-based design, for the
simple reason that it can be cheaper.  Think about it -- every flop is
really two latches!  (At least for static designs that can be clocked
down to DC...)  Where I work (at a chip company), we're still
occasionally converting latch-based designs into flop-based ones.

But (and this is a big but) FPGAs themselves (not just the design
tools) are designed for flop-based design, so if you use latch-based
designs with FPGAs you are not only stressing the timing tools, you
are also avoiding the nice, packaged, back-to-back dedicated latches
they give you called flops.

Pat


On Feb 11, 2:05=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> I finally understand the reason when a flip-flops can be replaced by a
> latch.
>
> Here is the excerpt from the paper "Atom Processor Core Made FPGA
> Synthesizable"
> Optimized for a frequency range from 800MHz to 1.86Ghz,
> the original Atom design makes extensive use of latches
> to support time borrowing along the critical timing paths.
> With level-sensitive latches, a signal may have a delay larger
> than the clock period and may flush through the latches
> without causing incorrect data propagation, whereas the delay
> of a signal in designs with edge-triggered flip-flops must
> be smaller than the clock period to ensure the correctness of
> data propagation across flip-flop stages [3]. It is well known
> that the static timing analysis of latch-based pipeline designs
> with level-sensitive latches is challenging due to two
> salient characteristics of time borrowing [2, 3, 14]: (1) a
> delay in one pipeline stage depends on the delays in the previous
> pipeline stage. (2) in a pipeline design, not only do
> the longest and shortest delays from a primary input to a
> primary output need to be propagated through the pipeline
> stages, but also the critical probabilities that the delays on
> latches violate setup-time and hold-time constraints. Such
> high dependency across the pipeline stages makes it very
> difficult to gauge the impact of correlations among delay
> random variables, especially the correlations resulting from
> reconvergent fanouts. Due to this innate difficulty, synthesis
> tools like DC-FPGA simply do not support latch analysis
> and synthesis correctly."
>
> In short, a pipeline with several FFs can be replaced with a pipeline
> with two FFs in the ends and normal latches inserted between them to
> steal time slack.
>
> FF1 ---> FF2 ---> FF3 ---> FF4
> FF1 ------->l2 --------> l3--> FF4.
>
> I saw the circuits before, but not realized what the basic reason was.
> With the above paper, I now know that the technology is not a new, it
> originated in 1980s.
>
> Weng


Article: 145489
Subject: Re: Synplify out of memory
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 12 Feb 2010 02:27:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ben Gelb <ben.gelb@gmail.com> wrote:

> I have a really large lookup table (members of a finite field) encoded
> as a function. This function is only ever invoked with a constant
> argument, so it shouldn't actually be synthesized. Altera's synthesis
> tool seems to handle this with no problem.
 
> When I try to use Synplify to synthesize my design (particularly this
> constant function), the verilog compiler (c_ver) runs out of memory
> (hits the 4GB limit).
 
> Seems like Synplify isn't figuring out that the function doesn't
> actually need to be synthesized.

That doesn't necessarily follow.  It may be doing a lot of work
while figuring out the value to be synthesized.

I have seen similar effects in Fortran compilers for compile
time constant tables, including running out of memory.
(Even for very small tables.)

-- glen
 

Article: 145490
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: Brian Davis <brimdavis@aol.com>
Date: Thu, 11 Feb 2010 18:31:58 -0800 (PST)
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
>
>> <snip> clamping the DONE voltage seen at the FPGA pin to one
>> VBE drop such that the FPGA thinks DONE never went high.
>
> Ha, THAT was it! Thank you, you made my day! Putting in the
> right value fixes the issue: Bit-files load without the
> DONE_cycle-setting, plus indirect SPI-programming works now.
>

Great! I hadn't seen that exact problem before, but the DONE LED
circuit found on many Xilinx/Digilent boards made me think of it:
:
: !!! Don't ever do this !!!
: Evil circuit clamps DONE high level to the LED's Vf
:
:  DONE >---o---/\/\---> VCC
:           |
:           |
:           v
:           - LED
:           |
:           |
:          GND

 Given that most Xilinx FPGAs have a Vih minimum threshold on
the DONE pin of 2.0 V (LVTTL, LVCMOS33) or 1.7 V (LVCMOS25),
it gives me the heebie-jeebies to see a circuit like that
clamping DONE to the LED Vf - depending upon the exact LED,
Vf could easily be down in the 1.5 V to 1.7 V range.

>
> The only question that remains is: why doesn't iMPACT give
> a "DONE did not go high"-message? If it did, I'd probably
> gotten there sooner.
>
 There are two DONE related bits in the V5 status register,
an internal "I-have-released-done" signal and then the actual
DONE pin state; I'd guess that iMPACT is reading the former.

 The FPGA startup state machine uses the external signal seen
on the DONE pin, so the FPGA will stall the startup sequence
with your accidental Vbe clamp on DONE.

 It would be interesting to compare the before and after
board-resistor-change state of the status register
[Debug->Read Device Status], post JTAG download attempt.

 There are other helpful bits in that status register for
troubleshooting exactly where the FPGA got stuck, here's a few:
"
" STARTUP_STATE [20:18] CFG startup state machine [ NOT BINARY
ENCODED!!!]
" DONE          [14]    Value on DONE pin
" RELEASE_DONE  [13]    Value of internal DONE signal
" EOS           [4]     End of Startup signal from Startup Block
"
from UG191 v3.8, V5 FPGA Configuration guide, page 120:
http://www.xilinx.com/support/documentation/user_guides/ug191.pdf

>
>Antti did post his version of such a core in the Xilinx user
>forums, though:
>
>http://tinyurl.com/yjtharz
>
 Thanks, I hadn't seen that one before.

Brian

Article: 145491
Subject: Re: What is the basis on flip-flops replaced by a latch
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 12 Feb 2010 02:33:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Patrick Maupin <pmaupin@gmail.com> wrote:

> Yes, latch-based design is much older than flop-based design, for the
> simple reason that it can be cheaper.  Think about it -- every flop is
> really two latches!  (At least for static designs that can be clocked
> down to DC...)  Where I work (at a chip company), we're still
> occasionally converting latch-based designs into flop-based ones.

Often using a two (or more) phase clock.  Some latches work on 
one phase, some on the other.  With appropriately non-overlapping,
one avoids race conditions and the timing isn't so hard to get right.

> But (and this is a big but) FPGAs themselves (not just the design
> tools) are designed for flop-based design, so if you use latch-based
> designs with FPGAs you are not only stressing the timing tools, you
> are also avoiding the nice, packaged, back-to-back dedicated latches
> they give you called flops.

Well, you could use a sequence of FF's, clocking on different clock
edges, or the same edge of two clocks.  

That allows for some of the advantages.  If there was enough demand,
I suppose FPGA companies would build transparent latch based devices.
(Who remembers the 7475?)

In pipelined processors of years past the Earle latch combined one
level of logic with the latch logic, reducing the latch delay.

-- glen

Article: 145492
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: vanepp@sfu.ca (Peter Van Epp)
Date: Fri, 12 Feb 2010 02:50:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> writes:

>On Feb 11, 2:50=A0pm, van...@sfu.ca (Peter Van Epp) wrote:
>> <snip>>And another question is: what else did the assembly house mess up =
>on
>> >this board? Lot of 0402 bird seed on this one, no way to tell by looking
>> >at it... But at least all supply voltages are correct and so on.
>>
>> <snip>
>>
>> =A0 =A0 =A0 =A0 This reminded me of an article I saw in Circuit Cellar on=
> Smart Tweezers
>> (http://www.smarttweezers.com) which might help you out. I expect there m=
>ay
>> be some problems in circuit with parallel paths though, I think it is mor=
>e
>> meant for identifying mystery components in isolation.
>>
>> Peter Van Epp

>We've got a set of these in our production area here, which is also
>the test and rework area (small company).  You can often get
>information
>in-circuit, especially in cases like this where you might see a much
>lower
>impedance than you were expecting.  They're also great for comparing
>two boards when one doesn't work, since whatever you measure on the
>good board (R L or C) is just a relative reference point rather than
>the presumed component value.

>Regards,
>Gabor

	Even better, someone that has actually used one (which I haven't :-)).

Peter Van Epp

Article: 145493
Subject: Re: Actel FPGA corePWM IP
From: RaulGonz <raullim7@hotmail.com>
Date: Thu, 11 Feb 2010 18:55:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Antti,

Do you happen to know if coreABC works in Libero IDE v8.6? I tried to
put in coreABC but the system prompted this error
"CoreABC_Generator.exe failed with code 32768". Please advise. Thank
you.

Article: 145494
Subject: QDRII on StratixIII pinout strangeness
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Fri, 12 Feb 2010 11:19:54 +0100
Links: << >>  << T >>  << A >>
Using QDRII  x18 in 2-burst mode, I assume that the data/adr/cmd bus are all 
DDR signals using the same clock domain (except the read and write signal 
wich are single data rate)

The docs say there are limitations on where to put the data bus, and then I 
can put the adr/cmd on what is left in the bank. This appears to be a bit 
weird, as in this mode they are all clocked in at the same DDR(K clk) 
domain.

Trying to compile it with swapped pins does give an error like:
"Error: Can't place I/O "d[4]" to I/O location Pin_AG6 because it does not 
support x18 mode memory interfaces"
AG6 is not in a x18 DQ bus, but its on the same bank as the other signals in 
the domain.

I wonder if anyone got experience with this. Is it just a lazy pinout guide 
that dates back from the modes where adr was single data rate? Or is there a 
hardware explanation?

Maybe there is a way to override the error message?

(Im clocking at half the max allowed, so there should be some overhead in 
timing)



Article: 145495
Subject: Re: Actel FPGA corePWM IP
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 12 Feb 2010 04:50:29 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 12, 4:55=A0am, RaulGonz <raull...@hotmail.com> wrote:
> Hi Antti,
>
> Do you happen to know if coreABC works in Libero IDE v8.6? I tried to
> put in coreABC but the system prompted this error
> "CoreABC_Generator.exe failed with code 32768". Please advise. Thank
> you.

works with 8.5 not sure about anything else
contact actel support, it should work with 8.6 also

Antti

Article: 145496
Subject: Re: using an FPGA to emulate a vintage computer
From: jmfbahciv <jmfbahciv@aol>
Date: Fri, 12 Feb 2010 08:17:41 -0500
Links: << >>  << T >>  << A >>
Rick wrote:
> On Feb 11, 6:27 am, jmfbahciv <jmfbahciv@aol> wrote:
>> Rick wrote:
>>> On Feb 10, 2:55 am, Olafur Gunnlaugsson <o...@audiotools.com> wrote:
>>>> Žann 05/02/2010 18:19, Eric Chomko skrifaši:
>>>>> Has anyone created a copy machine of an old system using an FPGA? I
>>>>> was wondering if it would be possible to take an entire SWTPC 6800 and
>>>>> compile the schematics and have it run on an FPGA board.? Wouldn't
>>>>> even have to be the latest Xylinx product, I suspect.
>>>> There are loads of such projects out there, even a commercial one called
>>>> C-One "the reconfigurable computer", here:http://www.c64upgra.de/c-one/
>>> It is a great effort but last time I checked it was a bit pricey ~$300
>>> for a basic system.
>> Just out of curiosity, how old are you?  Giving the decade is OK.
>> A game system is that price so I'm wondering if "kids" think $300
>> is too much.
>>
>> /BAH
> 
> 59. Directed at Olafur too, it isn't a question of value for goods
> delivered. Having recently priced getting some prototype boards made,
> I think they are priced appropriately.

Ah, OK.

> 
> I have a pretty good idea of ratio of shall we say sophisticated users
> to the Plebs. An analogy would be a Porsche is more expensive then
> riding a bus. The Plebs aren't concerned with file I/O, clock
> frequency, or storage. If they look back at all it is just to play a
> game of Pac Man or Bard's Tale. An emulator or SoC is fine and suited
> to their needs. This reduces the potiential market to hard core users.

If you had been a youngster, I would have poked a little bit more
to try to find out what kinds of things would interest you ;-).
I'm hearing rumors that the current young generation are interested
in learning about how all the insides work.

/BAH

Article: 145497
Subject: Test Post
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 12 Feb 2010 14:18:07 -0000
Links: << >>  << T >>  << A >>
I posted a query about 10 layer PCBs for a new board I'm
doing. I caught a reply by Rickman at home via Google, but
it seems to have disappeared now.

My usenet connection's normally pretty reliable so I'm not sure
what's going on.

Will this get out?


Nial.



Article: 145498
Subject: Re: Test Post
From: Gabor <gabor@alacron.com>
Date: Fri, 12 Feb 2010 08:11:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 12, 9:18=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> I posted a query about 10 layer PCBs for a new board I'm
> doing. I caught a reply by Rickman at home via Google, but
> it seems to have disappeared now.
>
> My usenet connection's normally pretty reliable so I'm not sure
> what's going on.
>
> Will this get out?
>
> Nial.

Google groups sees your post.  Also your thread is still showing
up there.  It doesn't show your thread as new, but rather as a
change in subject:

Board layout for FPGA
Discussion subject changed to "10 layer stack for 1152 pin BGA routing
(and decoupling)?" by Nial Stewart

Perhaps your newsreader still shows the original subject line?

Regards,
Gabor

Article: 145499
Subject: Re: What is the basis on flip-flops replaced by a latch
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Feb 2010 08:32:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 11, 3:05 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> I finally understand the reason when a flip-flops can be replaced by a
> latch.
>
> Here is the excerpt from the paper "Atom Processor Core Made FPGA
> Synthesizable"
> Optimized for a frequency range from 800MHz to 1.86Ghz,
> the original Atom design makes extensive use of latches
> to support time borrowing along the critical timing paths.
> With level-sensitive latches, a signal may have a delay larger
> than the clock period and may flush through the latches
> without causing incorrect data propagation, whereas the delay
> of a signal in designs with edge-triggered flip-flops must
> be smaller than the clock period to ensure the correctness of
> data propagation across flip-flop stages [3]. It is well known
> that the static timing analysis of latch-based pipeline designs
> with level-sensitive latches is challenging due to two
> salient characteristics of time borrowing [2, 3, 14]: (1) a
> delay in one pipeline stage depends on the delays in the previous
> pipeline stage. (2) in a pipeline design, not only do
> the longest and shortest delays from a primary input to a
> primary output need to be propagated through the pipeline
> stages, but also the critical probabilities that the delays on
> latches violate setup-time and hold-time constraints. Such
> high dependency across the pipeline stages makes it very
> difficult to gauge the impact of correlations among delay
> random variables, especially the correlations resulting from
> reconvergent fanouts. Due to this innate difficulty, synthesis
> tools like DC-FPGA simply do not support latch analysis
> and synthesis correctly."
>
> In short, a pipeline with several FFs can be replaced with a pipeline
> with two FFs in the ends and normal latches inserted between them to
> steal time slack.
>
> FF1 ---> FF2 ---> FF3 ---> FF4
> FF1 ------->l2 --------> l3--> FF4.
>
> I saw the circuits before, but not realized what the basic reason was.
> With the above paper, I now know that the technology is not a new, it
> originated in 1980s.
>
> Weng

I'm a little unclear on how this works.  Is this just a matter of the
outputs of the latches settling earlier if the logic path is faster so
that the next stage actually has more setup time?  This requires that
there be a minimum delay in any given path so that the correct data is
latched on the current clock cycle while the result for the next clock
cycle is still propagating through the logic.  I can see where this
might be helpful, but it would be a nightmare to analyze in timing,
mainly because of the wide range of delays with process, voltage and
temperature (PVT).  I have been told you need to allow 2:1 range when
considering all three.

I think similar issues are involved when considering async design (or
more accurately termed self-timed).  In that design method the
variations in delay affect the timing of both the data path and clock
path so that they are largely nulled out so that the min delays do not
need to include the full 2:1 range compared to the max.  Some amount
of slack time must be given so the clock arrives after the data, but
otherwise all the speed of the logic is utilized at all times.  This
also is supposed to provide for lower noise designs because there is
no chip wide clock giving rise to simultaneous switching noise.  Self-
timed logic does not really result in significant increases in
processing speed because although the max speed can be faster, an
application can never rely on that faster speed being available.  But
for applications where there is optional processing that can be done
using the left over clock cycles (poor term in this case, but you know
what I mean) it can be useful.

In the case of using latches in place of registers, the speed gains
are always usable.  But can't the same sort of gains be made by
register leveling?  If you have logic that is slower than a clock
cycle followed by logic that is faster than a clock cycle, why not
just move some of the slow logic across the register to the faster
logic section?

Rick



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