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 145375

Article: 145375
Subject: Re: Databus crossing clock domains with data freeze
From: "Al Momen" <almomen@gmail.com>
Date: Sun, 07 Feb 2010 07:33:49 -0600
Links: << >>  << T >>  << A >>
>This really belongs on comp.lang.verilog, but the topic 
>has been flogged to death there; and Verilog users on 
>comp.arch.fpga may find it vaguely relevant.
>
>On Wed, 06 Jan 2010 21:04:28 -0600, Nicholas Kinar wrote:
>
>>> What I don't understand is the assignment logic at the top of this 
>>> always block.  Isn't "old_slow_flag" equal to "resync_slow_flag"?
>
>No, it's not.  I carefully and correctly used a nonblocking
>assignment <=, causing a delayed update of the target.
>Whatever else you do, please get a robust understanding
>of the relationship between blocking = and nonblocking <=
>assignment before you do anything further with Verilog.
> 
>>To help me better understand this, I've re-written the code:
>>
>>reg old_slow_flag;
>>reg slow_flag;
>>
>>always @(posedge fast_clock) begin
>>
>>     if (old_slow_flag != slow_flag) begin
>>
>>       old_slow_flag <= slow_flag;
>>       freeze_register <= source_data;
>>
>>       // Do whatever it takes to indicate that
>>       // source_data has been consumed, and make
>>       // the next source_data available no more
>>       // than 2 fast clocks later
>>
>>     end
>>   end
>
>OK, I see what you're saying, but I'm afraid it's 
>completely wrong.  I'm not quite sure how to respond
>to this, but as a first try I'll explain why your
>code is broken and then show you a slightly different
>(and perhaps clearer) way to organize the design I 
>first offered.
>
>Error #1: Your model will never start running in
>simulation, because both regs initialize to 1'bX
>(as do all regs in Verilog) and the comparison
>   (old_slow_flag != slow_flag)
>evaluates to "unknown", because both sides of the
>equality are unknown.  When if() tests an unknown
>condition, it (by definition) takes the "else"
>branch; your code has no "else", so the if() 
>statement will do nothing.  Consequently the regs
>will remain stuck at X in simulation.  By contrast,
>synthesis can't handle X values and will give you
>the logic you expect; but that's probably wrong
>too, because....
>
>Error #2: slow_flag is generated in the source
>clock domain, and therefore may not have enough
>setup and hold time relative to the target clock.
>Consequently you could get an input hazard:
>the comparator result (old != new), which is used
>to enable various flipflops, might be detected
>"true" by some of the flops and "false" by others.
>That's why I took care to resynchronize it.
>
>Subsequently you said that the fast clock is known
>to be exactly 4x the slow clock; indeed, with a PLL,
>you can get the slow clock's edges exactly lined up
>with the fast clock's and you don't need to worry 
>about clock domain crossing at all.  That somewhat
>changes the goalposts, but my original solution 
>remains valid even when the two clocks are completely
>asynchronous.
>
>OK< so now let's go back to my example and see 
>(a) why it's right and (b) how I could recode it
>to be a little easier to follow.
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>THIS IS THE BIT THAT YOU REALLY MUST UNDERSTAND.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>  always @(posedge fast_clock) begin   // line 1
>    resync_slow_flag <= slow_flag;     // line 2
>    old_slow_flag <= resync_slow_flag; // line 3
>    if (old_slow_flag != resync_slow_flag) begin // 4
>      freeze_register <= source_data;
>      // Do other related things
>    end
>  end
>
>On line 1, the always block waits for the next clock 
>edge.  So far, so good.
>On line 2, we copy the asynchronous signal "slow_flag"
>into its resynchronizing register.  However, we use <= 
>nonblocking assignment, which means that the updating of
>resync_slow_flag is postponed until all other activity
>caused by the clock edge has finished.  This postponed
>signal update behaviour nicely models the clock-to-output
>delay of real flip-flops.  In particular, it means that...
>On line 3, we copy resync_slow_flag to old_slow_flag.
>But the value of resync_slow_flag that we copy HAS NOT YET
>BEEN UPDATED by the nonblocking assignment.  In other
>words, we get the flipflop's value as it was just before
>the clock edge.  Similarly, on line 4 the values tested
>by the if() expression are the values as they were just
>before the clock edge.  The same would be true if those
>values were tested in any other always block triggered by
>the same clock event; the value that you read is the value
>as it was just before (and also at the moment of) the clock 
>edge.  New values assigned using <= are projected future 
>values; they will take effect just after the clock edge 
>and, in particular, AFTER the execution of any always
>block that was triggered by the same clock.  This is 
>precisely how you get proper synchronous behaviour in
>Verilog RTL code.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>However, some folk (particularly those coming from a
>software background, where assignments always update 
>their targets immediately) find this sort of thing a little
>awkward to read.  So you can, if you wish, re-code the
>always block in a more software-like style provided you
>give it some local variables.
>
>  always @(posedge fast_clock) begin : my_resync // 1
>    reg resync_slow_flag, old_slow_flag;         // 2
>    if (old_slow_flag != resync_slow_flag) begin // 3
>      freeze_register <= source_data;            // 4
>      // Do other related things                 // 5
>    end                                          // 6
>    old_slow_flag = resync_slow_flag;            // 7
>    resync_slow_flag = slow_flag;                // 8
>  end
>
>By labelling the "begin" on line 1, we are entitled to
>declare local variables in the block (line 2).  Note that
>these variables are STATIC; they are NOT re-initialized
>each time the block executes, but instead they hold their
>value from its previous execution.
>On line 3 we test those variables' values; of course, the
>values we get are the values left over from the previous
>clock - that's flipflop behaviour.
>On lines 7 and 8 we update the variables using blocking
>assignment, which takes effect immediately.  Consequently
>we must respect your original concerns, and reverse the
>order of the two assignments so that the updating of
>old_slow_flag uses the old, rather than the updated, value
>of resync_slow_flag.
>
>This use of local variables has a number of benefits.  We
>have hidden the variables resync_* and old_* inside the
>begin...end block where they're used, and they are not
>(easily) accessible by other code that shouldn't be 
>concerned with them.  We go back to a software-like model
>of execution in which local variables update instantly.
>However, we MUST continue to use nonblocking assignment
>to freeze_reg because it will be read by other blocks
>of code, outside this particular always block.  Whenever
>you write to a variable within a clocked process, and that
>variable will be read by any other process, it's essential
>to use nonblocking assignment in this way or else you will
>get catastrophic race conditions in simulation, and mismatch
>between simulation and synthesis behaviour.
>
>Asks with trepidation..... where did you learn your Verilog,
>without finding out about the correct usage of <= ???
>-- 
>Jonathan Bromley
>
Hello Jonathan,

I have simulated your code, however, I am only capturing every other data
beats or the Even Data ( i.e. 0,2,4,6,8,..) the Odd Data beats are lost.

My Slow clock is (slow_period >= (2*fast_period) + (2/Fmax)) as an example
Fast clock 100Mhz, slow Clock at 48Mhz. The source data are bursts in at
the Fast clock frequency.

From your solution, it seems the source data are been sampled at slow_flag
or at the half of the fast clock rate. This will drop the second beats or
Odd data beats ( 1,3,5,7,.. Data Beats)
Please clarify, if I am missing something?






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

Article: 145376
Subject: Re: Databus crossing clock domains with data freeze
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sun, 07 Feb 2010 14:45:49 +0000
Links: << >>  << T >>  << A >>
On Sun, 07 Feb 2010 07:33:49 -0600, "Al Momen" wrote:

>I have simulated your code, however, I am only capturing every other data
>beats or the Even Data ( i.e. 0,2,4,6,8,..) the Odd Data beats are lost.
>
>My Slow clock is (slow_period >= (2*fast_period) + (2/Fmax)) as an example
>Fast clock 100Mhz, slow Clock at 48Mhz. The source data are bursts in at
>the Fast clock frequency.
>
>From your solution, it seems the source data are been sampled at slow_flag
>or at the half of the fast clock rate. This will drop the second beats or
>Odd data beats ( 1,3,5,7,.. Data Beats)
>Please clarify, if I am missing something?

I'm confused: do you get data on every cycle of the 100MHz clock?
If so, then you cannot expect to get every data item across
the interface unless you add some buffer storage (FIFO) on the
fast, source side.  The original question, for which I wrote
the specific answer, was about data transfer _with data freeze_;
in other words, the source data must be held until the slow,
target clock domain has taken it.  Clearly you can't do that
if you have new data on every cycle of the fast source clock.

FIFO storage allows you to buffer up a fast burst and then
transfer it slowly while the source is inactive.  But
that's not what the original question was about.  It
sounds as though your application needs a full-dress
two-clock FIFO.
-- 
Jonathan Bromley

Article: 145377
Subject: Re: using an FPGA to emulate a vintage computer
From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Sun, 07 Feb 2010 11:51:24 -0500
Links: << >>  << T >>  << A >>

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> I remember when I first started working with computers I had a
> book from our library about ECAP, IBM's Electronic Circuit
> Analysis Program.  I never saw or used the actual program,
> and haven't heard about it since.   I wonder where it went...

re:
http://www.garlic.com/~lynn/2010c.html#71 using an FPGA to emulate a vintage computer

no direct knowledge and web search is rather sparse ... a couple IEEE
citations:
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F23%2F4335780%2F04335910.pdf%3Farnumber%3D4335910&authDecision=-203
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F6%2F5218140%2F05218152.pdf%3Farnumber%3D5218152&authDecision=-203

in the aftermath of the troubles of the early 90s ... there was push to
move to industry standard tools ... part of which involved transfer of
internal tools to chip tool vendors (and some number of the internal
chip tools people spending a lot of time with these vendors ... and then
some number leaving and joining external vendor).

I've mentioned recently porting nearly 60k statement pascal program
(that did circuit layout) to other platforms, as part of such a tool
transfer.
http://www.garlic.com/~lynn/2010b.html#74 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010c.html#29 search engine history, was Happy DEC-10 Day

in the mid-80s ... internally, there was big push to expand a lot of
mainframe manufacturing capacity anticipating the market would double in
size by the early 90s. Not particularly "career enhancing" ... I made
some observation that computer hardware was becoming increasingly
commoditized ... resulting in thinner margins & profits ... which would
at least require significantly cutting the number of related employees
to stay out of the red. misc. past posts mentioning various (non)
"career enhancing":
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
http://www.garlic.com/~lynn/2007f.html#30 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007r.html#6 The history of Structure capabilities
http://www.garlic.com/~lynn/2008l.html#23 Memories of ACC, IBM Channels and Mainframe Internet Devices
http://www.garlic.com/~lynn/2009c.html#54 THE runs in DOS box?
http://www.garlic.com/~lynn/2009p.html#34 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers
http://www.garlic.com/~lynn/2009s.html#4 While watching Biography about Bill Gates on CNBC last Night

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

Article: 145378
Subject: Re: using an FPGA to emulate a vintage computer
From: James Dow Allen <jdallen2000@yahoo.com>
Date: Sun, 7 Feb 2010 13:44:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 7, 12:10=A0am, Al Kossow <a...@bitsavers.org> wrote:
> On 2/6/10 3:29 AM, James Dow Allen wrote:
> >  a National Semiconducter subsidiary once tried to
> > emulate an IBM 3033 at full speed using Fairchild 100k parts.
> > ... the reason for failure is interesting ...
> .
> I would be interested in what the reason for failure was.
> I assume it wasn't the obvious chip-chip delays using commodity
> ICs.

I think you mean that chip-chip delays would be too obvious
to be interesting.  :-)

The commodity high-speed ECL chips were almost in the
same ballpark as IBM's chips for speed and density, but
IBM's packaging was better in various ways.  The one
difference I found "interesting" and which seemed to be
a significant factor in the slowdown was that IBM used
smaller circuit boards.  Each signal was therefore
closer to the backplane, so closer to more chips total;
in other words the smaller circuit boards allowed IBM's
wiring to take better advantage, in some sense, of
the 3rd dimension!

I think there were other important factors in that
project's failure, but there's no need to start
any anti-NatSemi flamefest.  :-)

James Dow Allen

Article: 145379
Subject: Re: Simulating Spartan 3A pins in ltspice
From: Brian Davis <brimdavis@aol.com>
Date: Sun, 7 Feb 2010 19:33:05 -0800 (PST)
Links: << >>  << T >>  << A >>
Patrick Maupin wrote:
>
> Very good links!  Thanks!
>
If you get anywhere with this, please post an update!

A couple further notes/links:

--------------
An old thread on using the Intusoft translator with LTSpice:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/c4feb68203854343

--------------
Xilinx IBIS Package Models

 In the past few years, Xilinx has changed the package
models for their most recent FPGA families; the original
Tline-ahead-of-IBIS-parasitics method, that I had used in
that simple LTSpice example, has changed to a lumped model
with both coupled and uncoupled package data available.

 See my posts on the following thread for additional
notes and links regarding the changes to package models:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/3ff729ef8f851707

 ( in the really big BGA packages, Lpkg for the single lump
approach gets a bit unwieldy for high speed signals; I'd
probably break that Lpkg/Cpkg into several smaller lumps )

Brian

Article: 145380
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: Brian Davis <brimdavis@aol.com>
Date: Sun, 7 Feb 2010 20:04:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
>
> With ChipScope you can read out the internal configuration status
>
Note, you can also read the status in Impact 10.1 with:
 Debug->Read Device Status

FWIW another of my favorite Impact 10.1 settings is
 Edit->Preferences->Configuration Preferences->
 Startup Clock->Automatic Correction

>
> The question is: Why is that? Is it a bug in iMPACT? Does it
> stop clocking the configuration logic too soon? If so, why
> doesn't this happen on any other boards?
>
 If your normal method of configuration works fine, I wouldn't
worry too much about curable JTAG issues like that.

 I've seen that same sort of problem on a multi-chip V5
DONE cascade with Impact 10.1:
 http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a291d5c38abbd3c

And also on a Digilent S3 board when using their JTAG S/W:
 http://groups.google.com/group/comp.arch.fpga/msg/b06ca9faf716c347
 http://groups.google.com/group/comp.arch.fpga/msg/8f9c895ece739c6e

-------------

Random debug thoughts:

Configuration mode
 - are the chip mode pins set to JTAG, or another boot mode?
 - does changing the mode pins to JTAG affect the problem?

External DONE timing/levels
 - what value of pullup do you have on DONE pin?
 - are you using the "drive DONE" bitgen option?
 - what does the DONE risetime look like on the board?
 - have you tried the 'internal done pipe' bitgen option?
 - what happpens if you lower the JTAG clock rate?
 - is your DONE LED buffered? ( I've seen some boards with
   DONE LED hookups that load down the external DONE signal )

Brian

Article: 145381
Subject: Re: using an FPGA to emulate a vintage computer
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Sun, 07 Feb 2010 20:42:53 -0800
Links: << >>  << T >>  << A >>
On 02/06/2010 10:34 AM, Jecel wrote:
> I try to keep a reasonably updated list of such projects at
> 
> http://www.merlintec.com:8080/hardware/31

You can add to that list:

http://www.abc80.org/~hpa/fpga/

	-hpa

Article: 145382
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Sun, 7 Feb 2010 21:02:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 6, 2:01=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga rickman <gnu...@gmail.com> wrote:
> (snip)
>
> > My bad here. =A0I am the one saying that the planes will capacitively
> > couple and allow the return current to cross slots in one plane by
> > jumping to the other. =A0I got your post mixed up with Symon's post
> > where he recommends multiple ground planes stitched together with vias
> > rather than capacitively coupled power/ground planes.
>
> Well, you want it to stay low impedance all the way down to DC.

I don't get how this comment relates to the above.


> >> (snip, I wrote)
> >> I completely agree. ?Well, actually computers are probably about
> >> fast enough to do the whole calculation for at least one board trace
> >> using the actual geometry. ?With linearity you can compute each one
> >> and add them together. ?
> >> > Lee has done that. ?One test he made
> >> > that really impressed me was to show that a decoupling cap does not
> >> > need to be close to a pin to work well. ?If the power and ground pla=
ne
> >> > are closely spaced, the impedance is very low. ?If you understand
> >> > transmission lines, you will know that the current into (or out of) =
a
> >> > driver into the transmission line is constant until the signal reach=
es
> >> > the other end and depending on what load it finds, either continues
> >> > until the reflection returns to the driver (as in a series terminate=
d
> >> > line with high impedance load) or keeps flowing as when it reaches t=
he
> >> > decoupling cap. ?
> >> Well, it has the impedance of the transmission line itself.
> >> That depends on the inductance and capacitance of the conductors
> >> making up the transmission line. ?You can consider a linear
> >> transmission line as a sequence of series inductors and parallel
> >> capacitors of constant value per unit length. ?Consider the
> >> impedance of a finite length open ended transmission line as
> >> a function of frequency. ?For some frequencies the impedance will
> >> be very low, for others it will be very high. ?This property
> >> is used for impedance matching and filtering in RF circuits.
> > I am aware of what a transmission line is. =A0That is my point. =A0The
> > transmission line of closely spaced planes is a very low impedance
> > which supplies current for the full time it takes the impulse to reach
> > the cap. =A0So the spacing of the caps is not at all critical contrary
> > to what many will tell you.
>
> I believe, though, that radial transmission lines aren't
> discussed much in classes. =A0I hadn't thought of them much until
> I was replying to your post. =A0A google search for them brought
> up the paper that I tried to reference. =A0I did the search on a
> different computer and copied the link by hand. =A0I will try again.

The point is that they work very well for power decoupling.  The main
point in designing them is to keep the spacing between the plates
small so that the capacitance is high and the impedance is low.


> >> Now, consider the case of a signal going into or out of a supply
> >> plane. ?Now instead of the constant inductance and capacitance
> >> per unit length you have concentric rings. ?The inductance decreases
> >> and the capacitance increase with radial distance. ?In transmission
> >> line terms, it is a line with the impedance decreasing with R.
> >> Impedance decreases pretty fast, too. ?
> >> A quick web search finds a paper that looks interesting on just
> >> this problem. ?
> >>http://www.waves.utoronto.ca/prof/gleefth/Backup_Old/jpub/6.pdf
> >> The paper has much more detail than even I know, and includes
> >> comparisons of calculations and actual boards.
> > What paper? =A0I get a 404 error, page not found. =A0Still, I don't see
> > the problem you seem to be describing. =A0So the impedance drops with
> > increasing distance, low impedance in the power supply is a good
> > thing, no? =A0Why would it dropping be a bad thing?
>
> OK, try again.
>
> =A0 =A0http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/6.pdf

I still can't read it. 404 not found error again.


> he seems to even include the reflections of other vias, which
> seems more than is needed to me, but...
>
> It looks like the other papers on on slot antenna design,
> so he is considering PC board design in slot antenna terms.
>
> > Lee actually has impedance vs. frequency measurements of power/ground
> > planes and it is pretty interesting. =A0They don't do much below 100 MH=
z
> > or so, but beyond that the impedance is an up/down trace (all
> > adequately low) until it finally starts to climb above several GHz.
> > IIRC he explained the the sawtooth as having to do with the board
> > dimensions. =A0I guess it has something to do with standing waves, but
> > it was some four years ago and I don't recall for sure.
>
> With some bad luck you might get a resonance (standing wave)
> where the impedance didn't stay low.

Adding caps helps this in a couple of ways.  Each size cap has an
impedance min at different frequencies, but the fact that they are not
high Q and have ESR means they damp out the high peaks from
resonance.  It appears to work very well in Lee's measurements.


> > I do remember that he showed some interesting interactions between the
> > plane capacitance and the inductance of the small sized and valued
> > decoupling caps. =A0They have a resonance around 100-200 MHz I think,
> > which drives the impedance way up at that value. =A0His solution was to
> > add other value caps which effectively move that resonance and also
> > damp it out to where it is acceptable. =A0I think he showed a board
> > where he used a total of three different values of ceramic caps, but
> > only a small number of each, to get a very quiet board with a very
> > constant power delivery system impedance. =A0When I took the course, I
> > understood how to figure it all out, but I have not had a design with
> > difficult power decoupling needs, so I have forgotten some of it.
> > Good thing I still have the book... somewhere...
>
> In the old days, it might be that the tolerance kept the resonances
> from being too close. =A0The uniformity is so good now that they
> will all have resonance too close together.

It doesn't matter where the resonance is, the ESR keeps the peaks from
being very high and using multiple values makes the result pretty flat
or at least adequately low everywhere.


> > So the physics of each board is different??? =A0The board Lee
> > constructed was a test board. =A0I don't recall what he used for a
> > source of the transient, but he had spots for capacitors at a minimum
> > of three distances connected to the power/ground planes with optimally
> > short runs to the vias. =A0He populated the caps one at a time and
> > measured the effectiveness finding that it dropped off barely at all
> > at an inch, IIRC and only moderately at a couple or three inches. =A0Th=
e
> > point is that it is not really needed to put the cap right on top of
> > the power pin. =A0A good power/ground plane pair is much more
> > important.
>
> (snip)
>
> > My point is that this is all theory. =A0Unless you take some
> > measurements to verify what you are saying, you can't say it is an
> > accurate description of a real board and chip. =A0Also consider that on=
e
> > via is not a power supply. =A0Vias are used in parallel giving an
> > effectively low impedance.
>
> Hopefully the link is right now. =A0He does both theory and measurement.

I'll have to wait until another day.  BTW, does he actually relate
this to power supply decoupling or is this just a transmission line
analysis?

Rick

Article: 145383
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Sun, 7 Feb 2010 21:06:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 6, 7:44=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 2/6/2010 6:15 PM, rickman wrote:
>
> >> will increase with frequency.
>
> > My point is that this is all theory. =A0Unless you take some
> > measurements to verify what you are saying, you can't say it is an
> > accurate description of a real board and chip. =A0Also consider that on=
e
> > via is not a power supply. =A0Vias are used in parallel giving an
> > effectively low impedance.
>
> > Rick
>
> Rick,
> Do you measure every resistor you put on a board. Ohm's law is a theory,
> after all.
> Syms xx

I have measured a resistor's value before as well as the voltage and
current through it.  Then I knew that there was nothing amiss in the
circuit that I was not considering in my *theoretical* analysis of the
circuit.

Do you get the idea or are you still going to just arm chair
philosophize your power supply designs?

Rick

Article: 145384
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Sun, 7 Feb 2010 21:14:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 6, 7:37=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 2/6/2010 5:38 PM, rickman wrote:
>
> > I keep asking you if you have done any real analysis or measurements
> > of what you are stating?
>
> =A0>
>
> Well, this was the first time you asked IIRC, but thank you for doing
> so. The answer is "For sure". I've used Hyperlynx and Spice on my
> boards. I guess you have also, or else you would not be able to post
> your opinions without worrying you might giving someone a bum steer.

So are you going to share the results of these simulations on the vias
you are talking about?


> > I am no guru,
>
> Really?
>
> =A0>
>
> > but I was *very* impressed by
> > what Lee Ritchey said just because he has full support for just about
> > everything he stated in his course (except maybe that the food was
> > good at the Chinese restaurant).
>
> > Rick
>
> You seem to be _very_ impressed. Almost as impressed as Steve Wier.
>
> http://www.freelists.org/post/si-list/Lee-Ritcheys-book,4

I don't see anything that is a real criticism of Lee's ideas.  He is
critiquing the book and most of what he says are negative points are
actually editorial in nature.  He may not have all the background in
his book,, but everything he discussed in class was supported very
thoroughly.  I actually have not read the book in detail.  I use the
class handouts more I think.

Notice the reviewer's comment, "Chapters 32 - 37 on power distribution
issues are very good, with strong analysis, and practical solutions."
That is exactly the topic we are covering.

Rick

BTW, I am not trying to turn this into a pissing contest.  If you
don't like the way I am discussing this, I am happy to stop.

Article: 145385
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Sun, 7 Feb 2010 21:32:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 6, 9:13=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 2/7/2010 1:03 AM, glen herrmannsfeldt wrote:
>
> > Symon<symon_bre...@hotmail.com> =A0wrote:
>
> > (snip on bypass capacitors)
>
> >> What resonance?
>
> > The limit to the useful frequency range of a capacitor is
> > when it reaches resonance with the series (lead, package, etc.)
> > inductance. =A0 =A0Graph impedance vs. frequency, when the reactive
> > component crosses zero that it resonance.
>
> > -- glen
>
> Hi Glen,
> Are you sure? Even beyond that frequency the cap is still doing
> something, isn't it?
> Syms.

Yes, it is not so important whether the circuit is in the capacitive
or the inductive region.  What is important is the impedance.  So yes,
a capacitor can be an effective decoupling agent beyond its own
resonance.  But this is a bit different.  To be honest, I have not
analyzed a circuit like this and I expect it might be a bit more
complex than appears at first glance.  I expect a proper simulation is
in order.

Rick

Article: 145386
Subject: Re: Simulating Spartan 3A pins in ltspice
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sun, 7 Feb 2010 22:10:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 7, 9:33=A0pm, Brian Davis <brimda...@aol.com> wrote:

> If you get anywhere with this, please post an update!

Well, I did a bit of work on how I could do a differential input amp,
and between the small signal I wanted to decode, the offset voltage I
was probably looking at with using discretes, and the fact I wanted to
have controlled hysteresis, I decided to go with an external
comparator.  Microchip seems to have entered the market in a fairly
aggressive way; they hit the performance I need at a much better price
point than TI or Linear.

I could possibly use the internal receiver on the FPGA without an
external amplifier, but since Xilinx doesn't offer spice support and
the total market for this particular product probably isn't worth me
going in the lab and characterizing parts, I'm not going to do it.

On the one hand, I understand Xilinx's perspective, and at one level
it's a reasonable one -- they really only want to spend a lot on
supporting large customers doing fairly standard stuff.  On the other
hand, when I go back and re-read a few of the threads here, they do
seem a bit gruff about it.  For instance, when Steve Austin says that
the cost of HyperLynx is less than a single board spin, he's not
living in my world.  On this project, I'm trying out various things on
a board I can plug into a S3A starter kit.  Total cost of a spin is a
couple of hundred dollars, and lots of board rework can be tried
without actually doing a spin, and I don't anticipate any problems
that HyperLynx would actually solve for me in any case (especially
since I'm not a big customer that Xilinx would give an encrypted model
to).

Let me put it another way.  You can't sell a single Spartan 3A for
$5.40 at DigiKey or Avnet Express and expect that everyone who buys a
single FPGA will have all the fancy tools, and that nobody who buys a
single FPGA will have silly questions.  So, while I appreciate the
helpful information that Xilinx provides here, I also appreciate the
answers that I've seen you and Symon and rickman and countless others
give here over the years, and when I go back and read some of the
threads, it almost surprises me that some of you guys are still here
after some of the unwarranted flaming that you have received.

I've been using Xilinx parts for 13 years; been heavily involved in
projects which probably bought a total of over $2 million dollars of
parts from them, and a) I've never had to respin a board because of
any reason, much less SI (because I'm completely anal, and also
because I haven't done any really high-speed designs), and b) I've
never used anything remotely as complicated as HyperLynx.  Steve acts
like it's plug and play, but I've looked at stuff like that, and
honestly, if you don't do it every day, the cost of ramping up to do
it is as bad as the non-trivial license cost.

So, although some of us would like to think that the whole purpose of
buying an FPGA is to remove as much other stuff from the board as
possible, I guess we have to add using any of the analog on the chip
in a non-standard way to the long list of things that Xilinx doesn't
want us to do.  I just wish that we could convince them that it is
possible for them to document how things are implemented without them
having to support non-sanctioned use of the implementation.  Sometimes
I think headway is being made (like with the USB cable drivers under
Linux), but sometimes it is very frustrating, especially when a
feature like the differential receiver looks like it might be able to
save me an external 60 cent part, but they don't think it's worthwhile
to give me the information that would allow me to make that
determination for myself.

Anyway, thanks for the information.  I'm sure I will refer back to
this thread (and some of the previous threads) the next time I care
about detailed I/O pin characteristics.

Regards,
Pat

Article: 145387
Subject: Re: Simulating Spartan 3A pins in ltspice
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sun, 7 Feb 2010 22:10:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 7, 9:33=A0pm, Brian Davis <brimda...@aol.com> wrote:

> If you get anywhere with this, please post an update!

Well, I did a bit of work on how I could do a differential input amp,
and between the small signal I wanted to decode, the offset voltage I
was probably looking at with using discretes, and the fact I wanted to
have controlled hysteresis, I decided to go with an external
comparator.  Microchip seems to have entered the market in a fairly
aggressive way; they hit the performance I need at a much better price
point than TI or Linear.

I could possibly use the internal receiver on the FPGA without an
external amplifier, but since Xilinx doesn't offer spice support and
the total market for this particular product probably isn't worth me
going in the lab and characterizing parts, I'm not going to do it.

On the one hand, I understand Xilinx's perspective, and at one level
it's a reasonable one -- they really only want to spend a lot on
supporting large customers doing fairly standard stuff.  On the other
hand, when I go back and re-read a few of the threads here, they do
seem a bit gruff about it.  For instance, when Steve Austin says that
the cost of HyperLynx is less than a single board spin, he's not
living in my world.  On this project, I'm trying out various things on
a board I can plug into a S3A starter kit.  Total cost of a spin is a
couple of hundred dollars, and lots of board rework can be tried
without actually doing a spin, and I don't anticipate any problems
that HyperLynx would actually solve for me in any case (especially
since I'm not a big customer that Xilinx would give an encrypted model
to).

Let me put it another way.  You can't sell a single Spartan 3A for
$5.40 at DigiKey or Avnet Express and expect that everyone who buys a
single FPGA will have all the fancy tools, and that nobody who buys a
single FPGA will have silly questions.  So, while I appreciate the
helpful information that Xilinx provides here, I also appreciate the
answers that I've seen you and Symon and rickman and countless others
give here over the years, and when I go back and read some of the
threads, it almost surprises me that some of you guys are still here
after some of the unwarranted flaming that you have received.

I've been using Xilinx parts for 13 years; been heavily involved in
projects which probably bought a total of over $2 million dollars of
parts from them, and a) I've never had to respin a board because of
any reason, much less SI (because I'm completely anal, and also
because I haven't done any really high-speed designs), and b) I've
never used anything remotely as complicated as HyperLynx.  Steve acts
like it's plug and play, but I've looked at stuff like that, and
honestly, if you don't do it every day, the cost of ramping up to do
it is as bad as the non-trivial license cost.

So, although some of us would like to think that the whole purpose of
buying an FPGA is to remove as much other stuff from the board as
possible, I guess we have to add using any of the analog on the chip
in a non-standard way to the long list of things that Xilinx doesn't
want us to do.  I just wish that we could convince them that it is
possible for them to document how things are implemented without them
having to support non-sanctioned use of the implementation.  Sometimes
I think headway is being made (like with the USB cable drivers under
Linux), but sometimes it is very frustrating, especially when a
feature like the differential receiver looks like it might be able to
save me an external 60 cent part, but they don't think it's worthwhile
to give me the information that would allow me to make that
determination for myself.

Anyway, thanks for the information.  I'm sure I will refer back to
this thread (and some of the previous threads) the next time I care
about detailed I/O pin characteristics.

Regards,
Pat

Article: 145388
Subject: Re: Board layout for FPGA
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 8 Feb 2010 06:35:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)

>> ? ?http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/6.pdf
 
> I still can't read it. 404 not found error again.

OK, try again:

http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/

is the index of all his papers.

http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/pdf/6.pdf

should be the one.

http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/pdf/3.pdf

also looks like a related paper, and should probably be read first.
All seem to be unusual problems involving transmission lines.

(snip)
 
> I'll have to wait until another day.  BTW, does he actually relate
> this to power supply decoupling or is this just a transmission line
> analysis?

It is specific to power/ground planes on PC boards with vias.

-- glen

Article: 145389
Subject: Re: using an FPGA to emulate a vintage computer
From: Mike Hore <mike_horeREM@OVE.invalid.aapt.net.au>
Date: Mon, 08 Feb 2010 17:16:18 +0930
Links: << >>  << T >>  << A >>
(see below) wrote:
> On 05/02/2010 18:19, in article
> badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric
> Chomko" <pne.chomko@comcast.net> wrote:
> 
>> 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.
> 
> I think such a project would valuable, and perhaps even more valuable if it
> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
> KDF9, say. Perhaps even a Stretch.

A KDF9, maybe, but Stretch?  You'd have to be seriously masochistic, or 
downright insane  :-)

Cheers,  Mike.

---------------------------------------------------------------
      Mike Hore     mike_horeREM@OVE.invalid.aapt.net.au
---------------------------------------------------------------

Article: 145390
Subject: Re: using an FPGA to emulate a vintage computer
From: "invalid" <invalid@invalid.invalid>
Date: Mon, 8 Feb 2010 08:19:38 -0000
Links: << >>  << T >>  << A >>
"(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message 
news:C7921944.13537A%yaldnif.w@blueyonder.co.uk...
> On 05/02/2010 18:19, in article
> badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric
> Chomko" <pne.chomko@comcast.net> wrote:
>> 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.
> I think such a project would valuable, and perhaps even more valuable if 
> it
> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
> KDF9, say. Perhaps even a Stretch.
> KDF9 had about 20K transistors, a few K logic transformers, and a 
> comparable
> number of diodes; less than 50K devices in total. I imagine this would be
> easily accommodated on a modern FPGA. The big question would be whether to
> go for functional equivalence, or whether to try to replicate the original
> internal structures.

If you want funtional equivalence to the KDF-9 instruction set,
then get yourself a copy of the Forth language.



Article: 145391
Subject: Re: Matching hadware and software CRC
From: Krem <julien.lemer@gmail.com>
Date: Mon, 8 Feb 2010 00:33:37 -0800 (PST)
Links: << >>  << T >>  << A >>
For your information A really great tool to generate VHDL or verilog
files is here : http://www.easics.be/webtools/crctool

On Feb 6, 2:19=A0pm, "dlopez" <d@n_o_s_p_a_m.designgame.ca> wrote:
> >>However, the new problem is that I cannot feed in a data message,
> followed
> >>by the known good CRC, and get 0! This used to work before I added the
> >>above logic. =A0
>
> >You aren't supposed to get 0. =A0You get some magic constant.
>
> You are absolutely right. You also need to feed in the 'what used to be t=
he
> matching CRC' in reverse BYTE order (on top of reversing the bits).
>
> Now I'd like to understand why it doesn't give 0. This is what is mention=
ed
> in the 'painless guide to CRC error detection algorithm', line 575.http:/=
/www.ross.net/crc/download/crc_v3.txt
>
> ''At the other end, the receiver can do one of two things:
> =A0 =A0a. Separate the message and checksum. Calculate the checksum for
> =A0 =A0 =A0 the message (after appending W zeros) and compare the two
> =A0 =A0 =A0 checksums.
> =A0 =A0b. Checksum the whole lot (without appending zeros) and see if it
> =A0 =A0 =A0 comes out as zero!''
>
> I thought this was a nice approach since the receiver in the FPGA only
> needs to ever compare the CRC output with 0, instead of capturing the kno=
wn
> CRC (32 flops) and doing a full 32 bit compare. Although now with a magic
> constant it's pretty much the same.
>
> Diego =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com


Article: 145392
Subject: Re: using an FPGA to emulate a vintage computer
From: Gregory Estrade <gregory.estrade@gmail.com>
Date: Mon, 8 Feb 2010 01:05:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On 6 f=E9v, 19:34, Jecel <je...@merlintec.com> wrote:
> I try to keep a reasonably updated list of such projects at
>
> http://www.merlintec.com:8080/hardware/31
>
> -- Jecel

You can add those too :
http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued
http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga
http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga

Someday, I will set up a dedicated page for all these projects :)

Article: 145393
Subject: different JTAG programming cables
From: David Fejes <fejesd@gmail.com>
Date: Mon, 8 Feb 2010 01:11:32 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello guys,

is there any chance to get work a lattice jtag programming cable with
xilinx products? I think, JTAG is a common standard, didn't? I've a hw-
usbn-2a lattice cable and I want use with xilinx cplds, but the iMAPCT
doesn't find the cable.

If this is not possible, can anyone suggest a webstore in Europe where
I can order a xilinx JTAG cable? The digilent won't ship their
programming cables until 15.marc which is totally unacceptable. I've
phoned at least a dozen shop, but there is no ship within a month.

thank you in advance
David

Article: 145394
Subject: Re: different JTAG programming cables
From: John Adair <g1@enterpoint.co.uk>
Date: Mon, 8 Feb 2010 01:31:07 -0800 (PST)
Links: << >>  << T >>  << A >>
There is very little chance that a Lattice cable will work with Xilinx
software. It would be nice if the vendors got together and came up
with a way of any cable working with any software. However that is
about as likely as a green pig flying past my window.

For Xilinx cables in Europe you can buy them from Nuhorizons, Avnet
(Silica) and Farnell also have some.

We will be offering our own alternative  http://www.enterpoint.co.uk/programming_solutions/prog3.html
with development board sales within a few weeks. It will still be
cheaper option that a standalone Xilinx cable with the of lower end
boards that we sell. A few of our products on our shop website are
showing this option (preorder) and more will be added over the next
few weeks.

John Adair
Enterpoint Ltd. - Home of Merrick1. The FPGA High Performance
Processing Board.


On 8 Feb, 09:11, David Fejes <fej...@gmail.com> wrote:
> Hello guys,
>
> is there any chance to get work a lattice jtag programming cable with
> xilinx products? I think, JTAG is a common standard, didn't? I've a hw-
> usbn-2a lattice cable and I want use with xilinx cplds, but the iMAPCT
> doesn't find the cable.
>
> If this is not possible, can anyone suggest a webstore in Europe where
> I can order a xilinx JTAG cable? The digilent won't ship their
> programming cables until 15.marc which is totally unacceptable. I've
> phoned at least a dozen shop, but there is no ship within a month.
>
> thank you in advance
> David


Article: 145395
Subject: Re: Board layout for FPGA
From: David Brown <david@westcontrol.removethisbit.com>
Date: Mon, 08 Feb 2010 10:45:39 +0100
Links: << >>  << T >>  << A >>
On 05/02/2010 03:43, TSMGrizzly wrote:
>>
>> Are there any examples out there of how to route memory chips on a
>> bus? I'm kind of new to routing and don't really know what the
>> strategy is for this kind of thing. I was thinking about this when
>> designing a board to interface to expansion headers on a dev board for
>> a first prototype, but I couldn't think of a way to do it with just
>> two layers, so I gave each chip its own lines in that case since I had
>> plenty of I/O.
>
>
> Now that I think of it, I suppose I could make the bus connection job
> a little simpler if I take advantage of the fact that RAM is "random
> access," so the address/data line numbers from chip to chip don't
> necessarily have to match up. Then the address/data lines could be
> connected in whatever order is easiest and cleanest, since on the FPGA
> side the data would go in and come out in the desired order either
> way.
> Would this for any reason be a bad design practice?
>
> Steve

Are you thinking that, for example, pin D0 on one ram device is on the 
same bus line as pin D3 on the next ram device?  That's certainly 
possible - for static ram, there is no difference between the data lines 
or most of the address lines (if the ram supports bursting of some sort, 
then some address lines are specific).

However, the easiest way to connect multiple identical ram devices on a 
pcb is to simply place them close together and carefully aligned - then 
you can "bus route" between them with a neat pattern of routes straight 
across.  Only the chip select line is handled separately.  Mixing the 
bus numbering is not going to be of any benefit here, and it will make 
your schematics somewhat more confusing.



Article: 145396
Subject: Re: Board layout for FPGA
From: TSMGrizzly <sbattazz@yahoo.co.jp>
Date: Mon, 8 Feb 2010 04:24:59 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 8, 6:45=A0pm, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 05/02/2010 03:43, TSMGrizzly wrote:
>
>
>
>
>
> >> Are there any examples out there of how to route memory chips on a
> >> bus? I'm kind of new to routing and don't really know what the
> >> strategy is for this kind of thing. I was thinking about this when
> >> designing a board to interface to expansion headers on a dev board for
> >> a first prototype, but I couldn't think of a way to do it with just
> >> two layers, so I gave each chip its own lines in that case since I had
> >> plenty of I/O.
>
> > Now that I think of it, I suppose I could make the bus connection job
> > a little simpler if I take advantage of the fact that RAM is "random
> > access," so the address/data line numbers from chip to chip don't
> > necessarily have to match up. Then the address/data lines could be
> > connected in whatever order is easiest and cleanest, since on the FPGA
> > side the data would go in and come out in the desired order either
> > way.
> > Would this for any reason be a bad design practice?
>
> > Steve
>
> Are you thinking that, for example, pin D0 on one ram device is on the
> same bus line as pin D3 on the next ram device? =A0That's certainly
> possible - for static ram, there is no difference between the data lines
> or most of the address lines (if the ram supports bursting of some sort,
> then some address lines are specific).
>
> However, the easiest way to connect multiple identical ram devices on a
> pcb is to simply place them close together and carefully aligned - then
> you can "bus route" between them with a neat pattern of routes straight
> across. =A0Only the chip select line is handled separately. =A0Mixing the
> bus numbering is not going to be of any benefit here, and it will make
> your schematics somewhat more confusing.

Yes, that's what I was kind of thinking. It did occur to me that it
would add confusion to the schematics.
The devices are 44 pin TSOP-II packages, so I don't think I can
squeeze any traces between the pads, so I'm trying to think of two
things now.. how to get the traces to both sides of the chip in a tidy
way, and how to get the traces to daisy-chained chips (though out of
four chips, probably only two, maybe three will share a bus). I think
I've come up with a scheme, though it requires a little bit of layer
jumping, and the trace lengths will be different for each side of the
chip.. I don't suppose it matters much at this low speed though.

Looks like this thread has been pretty popular.. got lots of good
information to consider!
I have to get my first revision done and ordered in about four or five
weeks, so it's time to get to work!

Steve

Article: 145397
Subject: Re: using an FPGA to emulate a vintage computer
From: "(see below)" <yaldnif.w@blueyonder.co.uk>
Date: Mon, 08 Feb 2010 13:43:33 +0000
Links: << >>  << T >>  << A >>
On 08/02/2010 07:46, in article hkofgc$g56$1@news.eternal-september.org,
"Mike Hore" <mike_horeREM@OVE.invalid.aapt.net.au> wrote:

> (see below) wrote:
>> On 05/02/2010 18:19, in article
>> badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric
>> Chomko" <pne.chomko@comcast.net> wrote:
>> 
>>> 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.
>> 
>> I think such a project would valuable, and perhaps even more valuable if it
>> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
>> KDF9, say. Perhaps even a Stretch.
> 
> A KDF9, maybe, but Stretch?  You'd have to be seriously masochistic, or
> downright insane  :-)

Very possibly. 8-)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk



Article: 145398
Subject: Re: using an FPGA to emulate a vintage computer
From: "(see below)" <yaldnif.w@blueyonder.co.uk>
Date: Mon, 08 Feb 2010 13:52:50 +0000
Links: << >>  << T >>  << A >>
On 08/02/2010 08:19, in article hkohet$u7p$1@news.eternal-september.org,
"invalid" <invalid@invalid.invalid> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message
> news:C7921944.13537A%yaldnif.w@blueyonder.co.uk...
>> On 05/02/2010 18:19, in article
>> badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric
>> Chomko" <pne.chomko@comcast.net> wrote:
>>> 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.
>> I think such a project would valuable, and perhaps even more valuable if it
>> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
>> KDF9, say. Perhaps even a Stretch.
>> KDF9 had about 20K transistors, a few K logic transformers, and a comparable
>> number of diodes; less than 50K devices in total. I imagine this would be
>> easily accommodated on a modern FPGA. The big question would be whether to
>> go for functional equivalence, or whether to try to replicate the original
>> internal structures.
> 
> If you want funtional equivalence to the KDF-9 instruction set,
> then get yourself a copy of the Forth language.

While there are strong similarities between KDF9's Usercode assembly
language and FORTH, they are by no means functionally equivalent.

As it happens, I already have a prototype KDF9 running in my laptop -- but
implemented in software, not an FPGA. See:

   <http://www.findlayw.plus.com/KDF9>

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk



Article: 145399
Subject: Re: different JTAG programming cables
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Mon, 08 Feb 2010 09:12:40 -0500
Links: << >>  << T >>  << A >>
On Mon, 8 Feb 2010 01:11:32 -0800 (PST), David Fejes <fejesd@gmail.com>
wrote:

>Hello guys,
>
>is there any chance to get work a lattice jtag programming cable with
>xilinx products? I think, JTAG is a common standard, didn't? I've a hw-
>usbn-2a lattice cable and I want use with xilinx cplds, but the iMAPCT
>doesn't find the cable.
>
>If this is not possible, can anyone suggest a webstore in Europe where
>I can order a xilinx JTAG cable? The digilent won't ship their
>programming cables until 15.marc which is totally unacceptable. I've
>phoned at least a dozen shop, but there is no ship within a month.

Not EU but if you're on a deadline:
http://www.knjn.com/ShopJTAGcables_USB.html
http://www.knjn.com/ShopJTAGcables_Parallel.html

On the parallel page they do show a "universal" JTAG that can switch
between Altera and Xilinx.

-- 
Rich Webb     Norfolk, VA



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