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
2017JanFebMarApr2017

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 17775

Article: 17775
Subject: Re: microcontroller vs FPGA
From: Daniel Figuerola Estrada <pfa@tinet.fut.es>
Date: Thu, 02 Sep 1999 12:35:58 +0200
Links: << >>  << T >>  << A >>
Thak you very much to you all for your answers. It really helped me.
I would like also opinions for which of the two technologies is better
to implement the control system of a exchange-supplyer machine.

Also, would be better on an Altera MAX FPGA or a 81 family
microprocessor?

------------------------------------------------------------------------
 ////////////////////////////////\    ("`-''-/").___..--''"`-.__
 //  Marcel Figuerola Estrada   //      `6_ 6  )   `-.   (    ).`-.__.`)
 //       pfa@tinet.fut.es      //      (_Y_.)'  ._   )   `._ `.``-..-' 
 //  Valls - Catalunya - Europe //    _..`--'_..-_/  /--'_.'  ,' 
 \////////////////////////////////  (il),-''    (li),'  ((!.-'
------------------------------------------------------------------------

Article: 17776
Subject: Re: Virtex dev boards
From: Jeff Streznetcky <jeff.streznetcky@lmco.nospam.com>
Date: Thu, 02 Sep 1999 07:09:18 -0400
Links: << >>  << T >>  << A >>
See http://www.em.avnet.com/semis/ads/virtex.html

This development system card has a PCI interface, 512Kb of ZBT RAM, 16Mb of
SDRAM, 2Mb of Flash, a Fire-Wire port, two USB transceivers, An RS-232
interface, and a 80MHz RAM-DAC.

-Jeff


Sukandar Kartadinata wrote:

> I'm looking for a Virtex development board that has (supports) at least
> 16MBytes (or rather 4Mwords with 32bits word width, or 2Mx64bits) of
> fast SDRAM.
> Even better would be a board with two memory interfaces.
>
> Thanks for any suggestions
> Sukandar Kartadinata
> sk@zkm.de

Article: 17777
Subject: Re: Virtex dev boards
From: Jeff Streznetcky <jeff.streznetcky@lmco.nospam.com>
Date: Thu, 02 Sep 1999 07:09:46 -0400
Links: << >>  << T >>  << A >>
See http://www.em.avnet.com/semis/ads/virtex.html

This development system card has a PCI interface, 512Kb of ZBT RAM, 16Mb of
SDRAM, 2Mb of Flash, a Fire-Wire port, two USB transceivers, An RS-232
interface, and a 80MHz RAM-DAC.

-Jeff


Sukandar Kartadinata wrote:

> I'm looking for a Virtex development board that has (supports) at least
> 16MBytes (or rather 4Mwords with 32bits word width, or 2Mx64bits) of
> fast SDRAM.
> Even better would be a board with two memory interfaces.
>
> Thanks for any suggestions
> Sukandar Kartadinata
> sk@zkm.de

Article: 17778
Subject: Re: Virtex dev boards
From: Jeff Streznetcky <jeff.streznetcky@lmco.nospam.com>
Date: Thu, 02 Sep 1999 07:10:16 -0400
Links: << >>  << T >>  << A >>
See http://www.em.avnet.com/semis/ads/virtex.html

This development system card has a PCI interface, 512Kb of ZBT RAM, 16Mb of
SDRAM, 2Mb of Flash, a Fire-Wire port, two USB transceivers, An RS-232
interface, and a 80MHz RAM-DAC.

-Jeff


Sukandar Kartadinata wrote:

> I'm looking for a Virtex development board that has (supports) at least
> 16MBytes (or rather 4Mwords with 32bits word width, or 2Mx64bits) of
> fast SDRAM.
> Even better would be a board with two memory interfaces.
>
> Thanks for any suggestions
> Sukandar Kartadinata
> sk@zkm.de

Article: 17779
Subject: Re: QuickLogic FPGAs
From: "Keith Jasinski, Jr." <jasinski@mortara.com>
Date: Thu, 2 Sep 1999 08:48:34 -0500
Links: << >>  << T >>  << A >>
We've used them for many years.  Like any vendor, we've had our issues with
them.  They have always had good customer service and tech support and
resolved our problems to my satisfaction.  I would definately give them
above average marks.

--
Keith F. Jasinski, Jr.
kfjasins@execpc.com
Wayne Miller <wayne@aerial-imaging.com> wrote in message
news:37CE019E.6A7B3003@goodware.com...
> Anyone have any experience (good or bad) with FPGAs from QuickLogic?
>
>


Article: 17780
Subject: Re: FPGA/PLD in fine pitch BGA or chip scale package ???
From: mikeandmax@aol.com (Mikeandmax)
Date: 02 Sep 1999 16:26:57 GMT
Links: << >>  << T >>  << A >>
> FPGA/PLD in fine pitch BGA or chip scale package ???

Lattice also offers many device density/architecture choices in BGA and Tqfp
packages, with the recent acquisition of Vantis, Lattice has a very broad
choice in 5v and 3.3v
just my .02

Michael Thomas
Lattice SFAE
NY/NJ
Article: 17781
Subject: Re: What's meaning of "Partial Evaluation"
From: "Alvin E. Toda" <aet@lava.net>
Date: Thu, 2 Sep 1999 17:11:41 -1000
Links: << >>  << T >>  << A >>
Just a wild guess because the context is probably important.
Since many logic functions have don't care inputs, at that 
time not all of the of the minterns need to be evaluated.
Here partial may refer to an incomplete evaluation.

--alvin


On Wed, 1 Sep 1999 wudong99_1998@my-deja.com wrote:

> I read the phase "Partial Evaluation" from many papers but I don't know
> the exact meaning of it. Who can tell me the meaning or where I can
> find the meaning. Thanks!
> 
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
> 
> 

###########################################################
Alvin E. Toda              aet@lava.net
sr. engineer               Phone: 1-808-455-1331
2-Sigma          WEB: http://www.lava.net/~aet/2-sigma.html
1363-A Hoowali St.
Pearl City, Hawaii, USA

Article: 17782
Subject: Re: Feasibility of 200 MHz, 12K design on FPGA
From: Phil Hays <spampostmaster@sprynet.com>
Date: Thu, 02 Sep 1999 20:26:13 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> Designing to the architecture will have more bearing on whether or not you
> meet speed requirements than choice of tools.

The first is a requirement.  The second will make the job easier.


> I'd like to know how you proposed to floorplan Altera?  You can use the
> graphical floorplanner in the Maxplus tools, but if you iterate the design
> you have to start over.

It has been a couple of years since I did an Altera 10K design, but I
used the MaxPlus graphical floorplanner and I don't recall having to
start over.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan

Article: 17783
Subject: Re: QuickLogic FPGAs
From: Richard Guerin <guerin@IEEE.org>
Date: Fri, 03 Sep 1999 03:57:17 GMT
Links: << >>  << T >>  << A >>
We've used Quicklogic FPGAs for a couple of years .. Man, these things
are fast and easy to route ... love that SpDE tool ... main complaint is
lack of flops vs. chief anti-fuse competitor (Actel).


Wayne Miller wrote:
> 
> Anyone have any experience (good or bad) with FPGAs from QuickLogic?
Article: 17784
Subject: Technology Comparison of FPGAs families
From: Thierry Garrel <tga@magic.fr>
Date: Fri, 03 Sep 1999 06:15:04 +0200
Links: << >>  << T >>  << A >>
Il s'agit d'un message multivolet au format MIME.
--------------0BAE0BEA9F42B28CC4FABC6D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all, 

I'm searching for a technology comparison of FPGAs families betwwen
Xilinx, Altera, Actel, Quicklogic, Lucent, etc ... in terms of hardware
(capacity, technology, organisation, LUTs, routing ressoures, etc ...)

does anyone knows reports, thesis, papers, design notes ?

thanks you


Thierry GARREL
E-mail : tga@magic.fr

+--------------------------------------+
| MATRA SYSTEMES ET INFORMATION        |
| 6 avenue des tropiques - BP 80       |
| 91943 COURTABOEUF CEDEX / FRANCE     |
| Tel : (33) 1 69 86 85 00             |
| Fax : (33) 1 68 07 03 70             |
| Mail : ceo@matra-des.mgn.fr          |
+--------------------------------------+
--------------0BAE0BEA9F42B28CC4FABC6D
Content-Type: text/x-vcard; charset=us-ascii;
 name="tga.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Carte pour Thierry Garrel
Content-Disposition: attachment;
 filename="tga.vcf"

begin:vcard 
n:Garrel;Thierry
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:tga@magic.fr
x-mozilla-cpt:;-30144
fn:Thierry Garrel
end:vcard

--------------0BAE0BEA9F42B28CC4FABC6D--

Article: 17785
Subject: FreeDES and Free6502 Comments
From: Phil Hays <spampostmaster@sprynet.com>
Date: Thu, 02 Sep 1999 22:27:48 -0700
Links: << >>  << T >>  << A >>
I now have an evaluation copy of Exemplar's LS.  I've done a little with
the cores offered by the FreeIP page:

http://www.free-ip.com/

I downloaded the FreeDES and Free6502 source files, and had a look at
them.  I have several comments:

1) I can't yet get Leonardo Spectrum to do "Extended Optimization
Effort" on the FreeDES design, as this computer has only 64 MB of
memory, and LS seems to need about twice that.  The memory is on order,
I'll get it next week.  Not that it really matters much, but Synplify
(sum of several processes) seems to top out at 26 MB.  Memory is fairly
cheap compared to the tools, I would forgive a tool for needing more
memory if it just did a better job.  But so far, the size of resulting
output from LS is inbetween the results of Synplify and FPGA Express.  I
will post results when I can have the tool do all optimizations for
size.  I also want to look at speed.

2) The Free6502 core is an interesting design, as I think it could be
made to run at a rather higher clock rate.  To do this, I'm going to
make some suggestions for change in a step by step fashion.  I suppose I
might just propose a final design, but perhaps the step by step fashion
will allow for a better discussion as to why I want to make these
changes to speed up this design.  These changes may require microcode
changes: I'm not going to do that.  These changes will require running a
regression test to insure that the processor is still doing all
instructions correctly: I would run such a regression test if it was
automatic, but will not otherwise.

The longest path starts at the microcode address , goes through the ALU
and into the flags logic.  This path involves most of the design.  As it
is such a large amount of logic, and as it is the critical path, let us
start by adding a pipeline register.

The first change I propose is to add a pipeline register between the
output of the Microcode ROM and the rest of the design.  This will
reqire adding an extra state to the "state" statemachine that we might
call "decode", may require changes to the step counter and may require
microcode changes, both of which I did not do.  State "decode" will
always follow after "fetch".  This might add a clock to every
instruction, however any but will increase the clock rate from the
original 28.5 MHz to something over 45 Mhz (I did xilinx par using a
slower -4 part and hit 45 Mhz).


In the file free6502.vhd:

  type STATES is (RESET1, RESET2, FETCH, DECODE, START_IRQ, START_NMI,
RUN);
                                         ^add
  -- The main state machine
  process (clk, reset, nmi_event, irq_reg, i_flag, done)
  begin
    if reset='1' then
      state <= RESET1;
    elsif clk'event and clk='1' then
      case state is
        when RESET1 =>		state <= RESET2;
        when RESET2 =>		state <= RUN;
        when FETCH =>		state <= DECODE; -- change
        when DECODE=>           state <= RUN;    -- change

  -- The microcode step counter
  process (clk, reset, state)
  begin
    if reset='1' then
      step<="000";
    elsif clk'event and clk='1' then
      case state is
        when RESET1 =>          step <= "000";
        when RESET2 =>          step <= "000";
        when FETCH =>           step <= "000";
        when START_IRQ =>       step <= "000";
        when START_NMI =>       step <= "000";
        when DECODE =>          step <= step + 1; -- change

In the file MICROCODE.VHD:

architecture mc_rom_arch of mc_rom is
  signal addr :std_logic_vector (10 downto 0);
    signal DONE_c    : MCT_DONE;
    signal ADDR_OP_c : MCT_ADDR_OP;
    signal DIN_LE_c  : MCT_DIN_LE;
    signal RD_EN_c   : MCT_RD_EN;
    signal DOUT_OP_c : MCT_DOUT_OP;
    signal DINT1_OP_c: MCT_DINT1_OP;
    signal DINT2_OP_c: MCT_DINT2_OP;
    signal DINT3_OP_c: MCT_DINT3_OP;
    signal PC_OP_c   : MCT_PC_OP;
    signal SP_OP_c   : MCT_SP_OP;
    signal ALU1_c    : MCT_ALU1;
    signal ALU2_c    : MCT_ALU2;
    signal ALU_OP_c  : MCT_ALU_OP;
    signal A_LE_c    : MCT_A_LE;
    signal X_LE_c    : MCT_X_LE;
    signal Y_LE_c    : MCT_Y_LE;
    signal FLAG_OP_c : MCT_FLAG_OP;
begin
    --
    addr <= opcode & step;    
    --
    Process(clk) begin
        if rising_edge(clk) then
            DONE <= DONE_c;
            ADDR_OP <= ADDR_OP_c;
            DIN_LE <= DIN_LE_c;
            RD_EN <= RD_EN_c;
            DOUT_OP <= DOUT_OP_c;
            DINT1_OP <= DINT1_OP_c;
            DINT2_OP <= DINT2_OP_c;
            DINT3_OP <= DINT3_OP_c;
            PC_OP <= PC_OP_c;
            SP_OP <= SP_OP_c;
            ALU1 <= ALU1_c;
            ALU2 <= ALU2_c;
            ALU_OP <= ALU_OP_c;
            A_LE <= A_LE_c;
            X_LE <= X_LE_c;
            Y_LE <= Y_LE_c;
            FLAG_OP <= FLAG_OP_c;
        end if;
    end process;

  U00: DONE_rom port map (addr, DONE_c);
  U01: ADDR_OP_rom port map (addr, ADDR_OP_c);
  U02: DIN_LE_rom port map (addr, DIN_LE_c);
  U03: RD_EN_rom port map (addr, RD_EN_c);
  U04: DOUT_OP_rom port map (addr, DOUT_OP_c);
  U05: DINT1_OP_rom port map (addr, DINT1_OP_c);
  U06: DINT2_OP_rom port map (addr, DINT2_OP_c);
  U07: DINT3_OP_rom port map (addr, DINT3_OP_c);
  U08: PC_OP_rom port map (addr, PC_OP_c);
  U09: SP_OP_rom port map (addr, SP_OP_c);
  U10: ALU1_rom port map (addr, ALU1_c);
  U11: ALU2_rom port map (addr, ALU2_c);
  U12: ALU_OP_rom port map (addr, ALU_OP_c);
  U13: A_LE_rom port map (addr, A_LE_c);
  U14: X_LE_rom port map (addr, X_LE_c);
  U15: Y_LE_rom port map (addr, Y_LE_c);
  U16: FLAG_OP_rom port map (addr, FLAG_OP_c);
end mc_rom_arch;


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 17786
Subject: ALTERA Flex10K problems with lpm.
From: Gary Cook <gc@sonyoxford.co.uk>
Date: Fri, 03 Sep 1999 08:34:12 +0100
Links: << >>  << T >>  << A >>

--------------36DBA4D1F56D149BA530A076
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Putting a verilog design directly into MaxplusII for
a 10K40 device and having problems with LPMs.

If I instantiate lpm_addsub and use the defparam
to define the port width etc., it works fine if I do
this from the top-level of hierarchy. If then I place
the same instantiations and same defparams in a
lower level of hierarchy, the compiler complains that
the pin/stub names differ between the instantiation and
the Function Prototype ... it thinks it's got dataa-1,
where it should be dataa[LPM_WIDTH-1] ... it seems not
to be picking up the defparam correctly ...

Anyone got any ideas what may be causing this?

Also, while we're at it (so to speak!), I have an
asynchronous processor bus that I'm latching using
the Verilog "control = (~nEn)? data : control" and
then double clocking with the internal clock to
synchronise ... is this a valid way of doing it in
Altera? Not sure because I'm getting

  Design Doctor Warning: Unknown combinatorial latch
  detected at primitive 'xyz'

messages from design doctor ... I get these however
if I use their lpm_latch

Thanks in advance,

Gary Cook,
Oxford, UK.

--------------36DBA4D1F56D149BA530A076
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Hi,</tt><tt></tt>
<p><tt>Putting a verilog design directly into MaxplusII for</tt>
<br><tt>a 10K40 device and having problems with LPMs.</tt><tt></tt>
<p><tt>If I instantiate lpm_addsub and use the defparam</tt>
<br><tt>to define the port width etc., it works fine if I do</tt>
<br><tt>this from the top-level of hierarchy. If then I place</tt>
<br><tt>the same instantiations and same defparams in a</tt>
<br><tt>lower level of hierarchy, the compiler complains that</tt>
<br><tt>the pin/stub names differ between the instantiation and</tt>
<br><tt>the Function Prototype ... it thinks it's got dataa-1,</tt>
<br><tt>where it should be dataa[LPM_WIDTH-1] ... it seems not</tt>
<br><tt>to be picking up the defparam correctly ...</tt><tt></tt>
<p><tt>Anyone got any ideas what may be causing this?</tt><tt></tt>
<p><tt>Also, while we're at it (so to speak!), I have an</tt>
<br><tt>asynchronous processor bus that I'm latching using</tt>
<br><tt>the Verilog "control = (~nEn)? data : control" and</tt>
<br><tt>then double clocking with the internal clock to</tt>
<br><tt>synchronise ... is this a valid way of doing it in</tt>
<br><tt>Altera? Not sure because I'm getting</tt><tt></tt>
<p><tt>&nbsp; Design Doctor Warning: Unknown combinatorial latch</tt>
<br><tt>&nbsp; detected at primitive 'xyz'</tt><tt></tt>
<p><tt>messages from design doctor ... I get these however</tt>
<br><tt>if I use their lpm_latch</tt><tt></tt>
<p><tt>Thanks in advance,</tt><tt></tt>
<p><tt>Gary Cook,</tt>
<br><tt>Oxford, UK.</tt></html>

--------------36DBA4D1F56D149BA530A076--

Article: 17787
Subject: Re: Problem with VHDL in MAX+Plus II / Flex10k
From: german_acosta@my-deja.com
Date: Fri, 03 Sep 1999 16:17:18 GMT
Links: << >>  << T >>  << A >>
Thank you for your help and sorry for my english,
The more importan problem is that, I can assign more than one signal to
a bidirectional bus:

Activa_CPU:cpu
port map(...
	Read_mem => BRead_mem,
	BusData	 => BDataBus, 	--inout port (if use BDataBus here...)
        ...);

process(BRead_mem,...)
begin
   if Bread_mem=1 then
      BDataBus<= BusRam;	-- ...I can do that
   end if;
end process;

If I assign to the BDataBus signal in the component,  I can assign
another signal to BDataBus.

I tried using this structure, (as the example) and adding LPM_BUSTRI
into the component.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Article: 17788
Subject: Re: FreeDES and Free6502 Comments
From: David Kessner <davidk@free-ip.com>
Date: Fri, 03 Sep 1999 12:39:34 -0600
Links: << >>  << T >>  << A >>
Phil Hays wrote:

> 1) I can't yet get Leonardo Spectrum to do "Extended Optimization
> Effort" on the FreeDES design, as this computer has only 64 MB of
> memory, and LS seems to need about twice that.  The memory is on order,
> I'll get it next week.  Not that it really matters much, but Synplify
> (sum of several processes) seems to top out at 26 MB.  Memory is fairly
> cheap compared to the tools, I would forgive a tool for needing more
> memory if it just did a better job.  But so far, the size of resulting
> output from LS is inbetween the results of Synplify and FPGA Express.  I
> will post results when I can have the tool do all optimizations for
> size.  I also want to look at speed.

I have not used Leonardo, so I cannot say specifically what it
does.  But I can say that as a general rule, the DES core is a difficult
design for synthesis tools to handle.  It would not suprise me if
your machine needs 128 or 256 megabytes of RAM to work
effectively.  I'm using 256 meg and Synplify didn't have any
problems, but for some reason FPGA Express took forever
(6+ hours).


> 2) The Free6502 core is an interesting design, as I think it could be
> made to run at a rather higher clock rate.

You're right, it could be ran faster.  And you're also
right in thinking that the best place to start is by splitting
up the critical path with a pipeline register at the output
of the microcode ROM.  I considered this at one point,
but quite frankly I wanted to get the design "out" rather
than spend a 24+ hours rewriting the microcode.

Rewriting the microcode is not difficult, but it does
require intimate knowledge of the Free-6502 internals.

I should probably point out that this 6502 is not a
slow design, since it does run significantly faster than
currently available 6502 chips.  Imagine an Apple II
at 28 MHz!  But I also understand that faster speeds
are always desirable.



> To do this, I'm going to
> make some suggestions for change in a step by step fashion.

I think that the best forum to discuss this is in the Free-IP
mailing list.  There is a page on the web site that explains
how to subscribe to it.

The mailing list is better because we'll get into a lot of
detail that is probably only of interest to 10 or 20
other people in this news group-- and completely boring
to the other 2 thousand people.

But, given that, I'll respond to some of your points
here.  If you have more, then we should take it to
the mailing list.


> I suppose I
> might just propose a final design, but perhaps the step by step fashion
> will allow for a better discussion as to why I want to make these
> changes to speed up this design.

For the mailing list, you might bring up the entire list
of changes.  With a step-by-step approach it can
be difficult to keep track of some of the larger
architectural issues.


> These changes may require microcode
> changes: I'm not going to do that.

I have some tools to edit the microcode.  I
intended to make these tools available later,
once the design is more stable.


> These changes will require running a
> regression test to insure that the processor is still doing all
> instructions correctly: I would run such a regression test if it was
> automatic, but will not otherwise.

We currently do not have any tools for regression
testing.  I would appreciate it if someone made that
for the Free-6502 core.  (hint, hint :)


> The first change I propose is to add a pipeline register between the
> output of the Microcode ROM and the rest of the design.  This will
> reqire adding an extra state to the "state" statemachine that we might
> call "decode", may require changes to the step counter and may require
> microcode changes, both of which I did not do.  State "decode" will
> always follow after "fetch".  This might add a clock to every
> instruction, however any but will increase the clock rate from the
> original 28.5 MHz to something over 45 Mhz (I did xilinx par using a
> slower -4 part and hit 45 Mhz).

The "decode" state, and changes to the step counter are not
required.  What is required is that the entire microcode ROM
be rewritten.  Effectively, your "decode" state would be rolled
into the microcode.  By adjusting for the pipeline delay in the
microcode, more efficient use of the CPU core can be obtained.
For instance, this would add one clock to most instructions--
but not all!   It also allows some level of overlap between
execution of consecutive instructions.

Now that I said changes to the step counter is not required,
here's one change.  It would need to be expanded by one
bit.  I believe that the longest instruction is 8 clocks.
So if we added one clock to that, it would be 9 clocks
which would require a step counter that is slightly larger.
But that is the only change.


> Phil Hays
> "Irritatingly,  science claims to set limits on what
> we can do,  even in principle."   Carl Sagan

David Kessner
davidk@free-ip.com
http://www.free-ip.com


Article: 17789
Subject: Re: FreeDES and Free6502 Comments
From: jhallen@world.std.com (Joseph H Allen)
Date: Fri, 3 Sep 1999 21:45:30 GMT
Links: << >>  << T >>  << A >>
In article <37D015E5.A0F36C54@free-ip.com>,
David Kessner  <davidk@free-ip.com> wrote:
>Phil Hays wrote:

>> 2) The Free6502 core is an interesting design, as I think it could be
>> made to run at a rather higher clock rate.

>You're right, it could be ran faster.  And you're also
>right in thinking that the best place to start is by splitting
>up the critical path with a pipeline register at the output
>of the microcode ROM. 

One issue you might consider is whether or not you're trying for an exact
cycle-by-cycle duplication of the 6502.  I think you need to do that for the
cycle counting tricks programmers used, for example in the Atari 2600. It
would be neat if you could make a drop-in replacement for the 6502 that
would actually run in a classic computer (ignoring for now, the illegal
op-code issue).  I think your simple pipeline structure is close to what the
actual 6502 did- how else could they get 2-cycle branches?  Of course you
have you have to get decimal mode working too... (Atari 800 floating point
routines used it... unfortunately the decimal correction is in the ALU path
as well)

If you just want a speed increase there are other issues.  For example if
the average instruction is 3 cycles and the pipelining makes is 4 instead,
you are not getting much of an improvement: 9.5 MIPS (28MHz/3 cycles)
compared to 11.25 MIPS (45MHz/4 cycles).  Only about 20% faster.

The faster clock rate will require a faster memory as well, of course. 
Which brings up another issue- I don't really believe these speed numbers
anyway since the (very huge) address output logic is in the memory path. 
The critical delay might be address output logic - memory read - input
register setup time.  Of course adding an output register is going to add
even more cycles to the instructions.

The microcode ROM is huge in this design (2K by who knows how many bits
wide the synthesizer makes it).  I bet you could fix this by having separate
decode and sequencing ROMs.  I think there's only 32 actual instruction
sequences, so the ROM would become 256 words instead.  I bet you could do
even more shrinking by trying to create a more coherent internal bus
structure (instead of every register having a big mux in front of it).  For
example, maybe share the ALU input mux for the data output mux.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 17790
Subject: Re: FreeDES and Free6502 Comments
From: David Kessner <davidk@free-ip.com>
Date: Fri, 03 Sep 1999 16:19:20 -0600
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:

> >You're right, it could be ran faster.  And you're also
> >right in thinking that the best place to start is by splitting
> >up the critical path with a pipeline register at the output
> >of the microcode ROM.
>
> One issue you might consider is whether or not you're trying for an exact
> cycle-by-cycle duplication of the 6502.  I think you need to do that for the
> cycle counting tricks programmers used, for example in the Atari 2600. It
> would be neat if you could make a drop-in replacement for the 6502 that
> would actually run in a classic computer (ignoring for now, the illegal
> op-code issue).

With the Free-6502, I didn't attempt to make it cycle accurate.
The reason was simple.  In order to make it cycle accurate, I could
not register all inputs and outputs.  This would impact the instruction
rate drastically and make portability and ease of integration more
difficult.  Also, I figured that once you are running this thing at more
than 1 or 2 MHz then making it cycle accurate was much less
important.


> I think your simple pipeline structure is close to what the
> actual 6502 did- how else could they get 2-cycle branches?

My branches are 4 clocks, not two.  This is a good example
of why you can't register the I/O and make it cycle-accurate.
Here's a step-by-step, at the bus level, of a simple branch
(BCS, for instance):

    Clock 1:  Fetch the branch opcode from RAM
    Clock 2:  Fetch the branch address offset from RAM
    Clock 3:  Output the address of the next instruction.

If we registered the I/O then there would be no time
between Clocks 2 and 3 to calculate the new address
and output it.


> Of course you
> have you have to get decimal mode working too... (Atari 800 floating point
> routines used it... unfortunately the decimal correction is in the ALU path
> as well)

The ALU in the original 6502 and the Free-6502 is very
different.  In the original 6502 the ALU calculates normal
stuff, as well as addresses.  That is, when you do an indirect
address the ALU does the address addition.  In the Free-6502
there is a separate ALU for that.  I did it this way for
speed and simplicity.  The original 6502 did it that way to
conserve logic in its old technology.

Decimal mode is the main thing on the wish list, right after
having a more complete test suite.


> If you just want a speed increase there are other issues.  For example if
> the average instruction is 3 cycles and the pipelining makes is 4 instead,
> you are not getting much of an improvement: 9.5 MIPS (28MHz/3 cycles)
> compared to 11.25 MIPS (45MHz/4 cycles).  Only about 20% faster.

Right, which was another reason why I didn't bother to
pipeline the microcode ROM and rewrite the microcode.



> The faster clock rate will require a faster memory as well, of course.
> Which brings up another issue- I don't really believe these speed numbers
> anyway since the (very huge) address output logic is in the memory path.
> The critical delay might be address output logic - memory read - input
> register setup time.  Of course adding an output register is going to add
> even more cycles to the instructions.

Since all I/O are registered, when you have a 25 MHz clock you
actually get 40 ns worth of time to access memory (minus the
standard setup and hold times for the registers).


> The microcode ROM is huge in this design (2K by who knows how many bits
> wide the synthesizer makes it).

If the actual microcode ROM was done as a standard ROM then
you would need a 2k x 35 bit ROM.  But it's not.  If you did a 2kx35
ROM in Xilinx CLB's it would take over 2200 CLB's, yet the entire
Free-6502 core takes about 620 CLB's.  Obviously there is some
really slick optimizations going on, <wink wink>.


> I bet you could fix this by having separate
> decode and sequencing ROMs.  I think there's only 32 actual instruction
> sequences, so the ROM would become 256 words instead.

I'm not sure that having separate decode/sequencing ROM's would
help it.  The current microcode is fairly compact.


> I bet you could do
> even more shrinking by trying to create a more coherent internal bus
> structure (instead of every register having a big mux in front of it).  For
> example, maybe share the ALU input mux for the data output mux.

I'm sure that there is some optimization that could be done here.
But, that's why the source code is public-- so people like you can
come up with ways to improve it!


> /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */

David Kessner
davidk@free-ip.com        http://www.free-ip.com/


Article: 17791
Subject: Re: FreeDES and Free6502 Comments
From: jhallen@world.std.com (Joseph H Allen)
Date: Sat, 4 Sep 1999 00:45:04 GMT
Links: << >>  << T >>  << A >>
In article <37D04968.20C1E1B6@free-ip.com>,
David Kessner  <davidk@free-ip.com> wrote:

>Since all I/O are registered, when you have a 25 MHz clock you
>actually get 40 ns worth of time to access memory (minus the
>standard setup and hold times for the registers).

Oh sorry, I was confused.  There is an address output register after all- I
missed the clk'event.... line.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 17792
Subject: Re: synthesis comparion between Synplify and FPGA express
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Fri, 3 Sep 1999 17:45:31 -0700
Links: << >>  << T >>  << A >>
I just went through a synthesis round with an Insight FAE.  He took my
design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA
Express) and compiled it with Synplicity.  It would not fit in the Virtex
part (112%), and completely used up the 4020XLA (100%).  I'm not sure if it
met speed with Synplicity.  Synopsys used 78% of the Virtex, and about 62%
of the 4020 (which is interesting in itself, since the Virtex supposedly has
more gates - HA!).


It was a pure "logic" design with lots of registers, state machines and a
few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to
10 or more levels of logic).

In the process, he uncovered several Synplicity bugs that were no problem
for Synopsys.

I believed the "Synplicity is better" stuff, and had it do better on a few
state machine test cases (where I had problems with Synopsys), but for the
"big" design, it went south big time.  I'll stick with Synopsys, thank you.

Bruce




David Kessner wrote in message <37C16162.64AFC906@free-ip.com>...
>Phil Hays wrote:
>
>> muzo wrote:
>> > just check-out http://www.free-ip.com/DES/index.htm and look for the
>> > comparisons between Synplify and FPGA express.
>>
>> This comparison just isn't very meaningful.  It's based on a single flaw
>> in FPGA Express.
>
>> From the above URL:
>>
>> "This was traced down to the S-Boxes, which are implemented as 64x4
>> ROM's.  Under FPGA Express, these took about 33 slices where Synplify
>> took 10 slices."
>
>Seeing as I wrote that statement (from the above URL), I guess I should
>put my two cents worth in here...
>
>The comparison of FPGA Express and Synplify, with respect to the
>Free-DES core, is very meaningful but only in applications where ROM's
>are implemented (which I admit is limited).  This has a huge impact for
>DES since there are so many ROM's, but it can also have an impact for
>some CPU (microcode rom), and DSP (coefficient tables) applications.
>
>I did a comparison between Synplify and FPGA Express and Synplify
>was better in all applications that I tried-- but the DES code was the
>most drastic.  Ignoring the Free-DES core for the moment, typical
>improvements for Synplify was 10 to 20% less logic _OR_ a 10 to 60%
>improvement in speed.  This was based on UART, CPU, and Ethernet
>controller designs.  Of course, your mileage will vary.
>
>My only complaint about Synplify is that their way to do constraints seems
>awful to me.  It may work, but I like what FPGA Express does much
>better.
>
>
>
>> If the team at Synopsis is serious about staying in business, this flaw
>> will be fixed in a matter of months.
>
>The latest version of FPGA Express (I forget the version #, but it
>is what's shipping this month with Xilinx Foundation/Alliance 2.1)
>does not fix this problem.
>
>
>
>> I'm tempted to update my evaluation license for Exemplar (which I think
>> has averaged as the number two tool in my past evaluations) just to try
>> this design.
>
>That would be good.  Try the Free-6502 as well.  I'd like to put those
>results up on the Free-IP Project web site...
>
>
>Thanks.
>
>David Kessner
>davidk@free-ip.com
>http://www.free-ip.com
>
>


Article: 17793
Subject: Flex8000 trouble
From: Armin Mueller <ual6@rz.uni-karlsruhe.de>
Date: Sat, 04 Sep 1999 16:58:29 +0200
Links: << >>  << T >>  << A >>
Hello,

I'm just implementing some video stuff on an Altera Flex8000.
At some points the chip behaves unexpected:

I have a 4 word FIFO. "dblbuf" is the DMA input and has a 
constant value for testing pupose, "word" is the FIFO counter,
"buffer" is the FIFO memory. All pins are fixed, but the device
usage is below 50%. "dllc2" is about 7 Mhz.

When simulating, everything works fine. In practice, the buffer
sometimes drops information which should be static and constant!!!

Worse, when I shift the buffer contents by 16 bits fixed,
it drops information even during simulation (routing dependent).

What's wrong? Is the chip so prone to routing? Is the compiler
reducing something to asynchrone logic? Are the LPM modules
more stable?

Armin



dblbuf[15..0]	: dff;		-- constant
buffer[63..0]	: dff;
word  [1..0]	: dff;

buffer[].clk	= dllc2;
case word[].q is
	when  0 =>	buffer[15.. 0].d = dblbuf[];
			buffer[63..16].d = buffer[63..16].q;
	when  1 =>	buffer[15.. 0].d = buffer[15.. 0].q;
			buffer[31..16].d = dblbuf[];
			buffer[63..32].d = buffer[63..32].q;
	when  2 =>	buffer[31.. 0].d = buffer[31.. 0].q;
			buffer[47..32].d = dblbuf[];
			buffer[63..48].d = buffer[63..48].q;
	when  3 =>	buffer[47.. 0].d = buffer[47.. 0].q;
			buffer[63..48].d = dblbuf[];
end case;

Article: 17794
Subject: Re: synthesis comparion between Synplify and FPGA express
From: a@z.com
Date: Sat, 04 Sep 1999 13:22:46 -0400
Links: << >>  << T >>  << A >>
Can you share your design with the group so we can have an independent
verification of your reports? If it is true than a huge leap forward has been
made by FPGA Express which until now was trailing badly both Synplicity and
Exemplar LS.

On the other hand you could try the FreeDES design at http://www.free-ip.com.
The author was not able to use FPGA Express at all (synthesis took over 6
hours).

What were the versions of the FPGA Express and Synplicity tools you used?

Catalin Baetoniu

Bruce Nepple wrote:

> I just went through a synthesis round with an Insight FAE.  He took my
> design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA
> Express) and compiled it with Synplicity.  It would not fit in the Virtex
> part (112%), and completely used up the 4020XLA (100%).  I'm not sure if it
> met speed with Synplicity.  Synopsys used 78% of the Virtex, and about 62%
> of the 4020 (which is interesting in itself, since the Virtex supposedly has
> more gates - HA!).
>
> It was a pure "logic" design with lots of registers, state machines and a
> few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to
> 10 or more levels of logic).
>
> In the process, he uncovered several Synplicity bugs that were no problem
> for Synopsys.
>
> I believed the "Synplicity is better" stuff, and had it do better on a few
> state machine test cases (where I had problems with Synopsys), but for the
> "big" design, it went south big time.  I'll stick with Synopsys, thank you.
>
> Bruce
>

Article: 17795
Subject: Re: FreeDES and Free6502 Comments
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sat, 04 Sep 1999 14:24:55 -0700
Links: << >>  << T >>  << A >>
David Kessner wrote:

> > 2) The Free6502 core is an interesting design, as I think it could be
> > made to run at a rather higher clock rate.
> 
> You're right, it could be ran faster.  And you're also
> right in thinking that the best place to start is by splitting
> up the critical path with a pipeline register at the output
> of the microcode ROM.  I considered this at one point,
> but quite frankly I wanted to get the design "out" rather
> than spend a 24+ hours rewriting the microcode.

I was hoping that it would not be necessary to rewrite microcode.  My
idea for keeping the existing microcode was to use the MCT_DONE to stop
the sequence counter and force other microcode bits do do nothing for
one cycle, accounted for by adding a DECODE state.  I reran PAR with the
-6 part, and the clock speed was 65 MHz without forcing registers into
IOBs and 59 MHz with forcing registers into IOBs.

> I should probably point out that this 6502 is not a
> slow design, since it does run significantly faster than
> currently available 6502 chips.  Imagine an Apple II
> at 28 MHz!  But I also understand that faster speeds
> are always desirable.

Well them, imagine an Apple II at 65 MHz or more.  Speed is nice:  I
think that a 6502 could be made to run at 133 MHz using the internal
block RAMs for program storage and microcode.  However, for some
applications keeping the timing of instructions is important.  Many
Apple II games wouldn't be playable as they relied software speed to
control the speed of the game.  For some control application, you might
even want to run at 2 MHz with exact cycle by cycle bus activity so as
not to break existing software.


> I think that the best forum to discuss this is in the Free-IP
> mailing list. 

Perhaps so, for improvements to the Free6502 core.  However, I do still
intend to post some results here comparing Synplify and Exemplar LS.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 17796
Subject: Re: FreeDES and Free6502 Comments
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sat, 04 Sep 1999 14:39:15 -0700
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:

> If you just want a speed increase there are other issues.  For example if
> the average instruction is 3 cycles and the pipelining makes is 4 instead,
> you are not getting much of an improvement: 9.5 MIPS (28MHz/3 cycles)
> compared to 11.25 MIPS (45MHz/4 cycles).  Only about 20% faster.

Perhaps I should have waited for running PAR with the same part, and
even re-did the non-pipelined case.  The 28.5 MHz number came from a -6
part, and the 45 MHz number came from a slower -4 part.  With a -6 part
the pipelined design runs at 59 MHZ or twice as fast.  It's still not
clear to me if the results are comparable: PAR produces better results
when you tell it to try harder, which I was doing, and I'm not sure how
hard PAR was told to try for the first number.

Also, the pipeline register makes the design easier to floorplan.  It is
far easier to floorplan registers than logic when using HDL tools, as
the registers usually have fixed names, and the logic only does if you
take pains to make it so.

Lastly, the Xilinx Vertex (and Altera's latest) have fairly large RAMs
that are pipelined, and could be used as microcode ROMs.  Once the data
path is cleaned up a bit, this would allow for size reduction and speed
increase of the microstore.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 17797
Subject: Newbie question: Reading FPGA programming?
From: bureauc@hotmail.com (X)
Date: Sun, 05 Sep 1999 14:06:51 GMT
Links: << >>  << T >>  << A >>
Here's a question that may or may not be an ignorant one (if it is,
just point me to a FAQ that explains it). I have a circuit of unknown
orign containing an Actel A1010B.  This is an anti-fuse based part, I
believe, set up to do address decoding. I want to make modifications
to this circuit, but I don't have the original design documentation.
Is it possible to read out the programming of this part, in order to
understand exactly what it is doing and what changes are needed? I
have not been able to find anything that describes how to do this, or
even if it can be done.

TIA

smith
Article: 17798
Subject: Re: Newbie question: Reading FPGA programming?
From: Ray Andraka <randraka@ids.net>
Date: Sun, 05 Sep 1999 13:27:49 -0400
Links: << >>  << T >>  << A >>
If the protection fuse is 'unblown' then you won't be able to read it
back no matter what.  If not, then you could read back the bitstream, but
it is not going to mean much to you.  The translation from logic to
bitstream is not generally published, and it is a monumental effort to
reverse engineer.  So the short answer is: you're out of luck.

X wrote:

> Here's a question that may or may not be an ignorant one (if it is,
> just point me to a FAQ that explains it). I have a circuit of unknown
> orign containing an Actel A1010B.  This is an anti-fuse based part, I
> believe, set up to do address decoding. I want to make modifications
> to this circuit, but I don't have the original design documentation.
> Is it possible to read out the programming of this part, in order to
> understand exactly what it is doing and what changes are needed? I
> have not been able to find anything that describes how to do this, or
> even if it can be done.
>
> TIA
>
> smith



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 17799
Subject: Re: Newbie question: Reading FPGA programming?
From: rk <stellare@NOSPAM.erols.com>
Date: Sun, 05 Sep 1999 14:11:25 -0400
Links: << >>  << T >>  << A >>
hi,

yes, the a1010b is an antifuse part having 295 logic modules.  i don't
know any way to read out the programming pattern, let alone make it into
a schematic.  visual examination of the die won't help, even with a sem.
cross-sectioning isn't so easy, either, and is not practical for decoding
a chip.  it takes a bit of patience and some sophisticated gear to do
much of anything.

if the security fuse is not programmed, you can use their debug feature
to see what's going on.  you shift in codes and then you can monitor the
output of any module you select.  this is documented in the actel data
book.

jones

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

X wrote:

> Here's a question that may or may not be an ignorant one (if it is,
> just point me to a FAQ that explains it). I have a circuit of unknown
> orign containing an Actel A1010B.  This is an anti-fuse based part, I
> believe, set up to do address decoding. I want to make modifications
> to this circuit, but I don't have the original design documentation.
> Is it possible to read out the programming of this part, in order to
> understand exactly what it is doing and what changes are needed? I
> have not been able to find anything that describes how to do this, or
> even if it can be done.
>
> TIA
>
> smith





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
2017JanFebMarApr2017

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