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 146100

Article: 146100
Subject: Re: FSM in BlockRAM
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 5 Mar 2010 09:13:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 8:08=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Mar 5, 2:41=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> > On 3/5/2010 11:39 AM, de4 wrote:
>
> > > Can someone show me an example of code in VHDL of simple state machin=
e that
> > > can be packed in to BRAM with any warnings, errors. I just worry that=
 my
> > > design won't work. I have ISE 11.1 and Spartan 3a...
>
> > XAPP291
>
> xapp291 does NOT show how from SM VHDL code a implementation using
> BRAM is generated by the tools
>
> Antti

This is a very simple design, easily implemented in  BRAM (if speed
permits)
You have 7 states, therefore you need 3 (encoded) outputs
You have 6 incoming condition or jump codes.
You use the BRAM as a synchronous look-up table, using as address the
combination of any jump code with any state code.
That means you need 9 inputs, and the BRAM is thus 512 x 3. ( "512 x
6" in your posting is nonsense)
In hardware you must feed the three output bits back to the address
inputs.

You can use any additional otherwise unused outputs as decoded state
descriptors, but that does not change the basic design.

I suppose you know that the addressing information is automatically
registered before it addresses the BRAM (which is really a BROM with
fixed data content)
Do not use any additional output pipelining, optionally available in
some devices.

Unfortunately I cannot give you any VHDL code, but the basic
understanding should help you.

I have described and promoted this type of design for many years.

Peter Alfke, formerly Xilinx Applications (some of you may remember me)

Article: 146101
Subject: Re: using an FPGA to emulate a vintage computer
From: Quadibloc <jsavard@ecn.ab.ca>
Date: Fri, 5 Mar 2010 09:14:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 22, 2:53=A0pm, Eric Chomko <pne.cho...@comcast.net> wrote:
> This was pre-RISC days and the whole computer
> architecture idea
> based upon a high-level language never really took off. Nor did the
> use of a medium
> level language like Forth as far as I can tell.

Well, naturally not.

Both of those ideas got you less performance per dollar than the use
of a conventional architecture, with compilation by a highly-
optimizing FORTRAN compiler.

I mean, computer cycles cost real money in those days.

Later on, in the microcomputer era, the even less efficient use of
interpreters like BASIC was popular because it was an easy way to
bridge the gap between what the microprocessors could do, and what was
convenient for people to program in. But serious applications - which,
in the case of home computers, largely meant video games - were
programmed in assembler, until things improved to the point where C
was an alternative.

John Savard

Article: 146102
Subject: Re: Modelsim PE vs. Aldec Active-HDL (PE)
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Mar 2010 09:15:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 5:34=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> Andy Peters <goo...@latke.net> writes:
> > ModelSim has one project file (the .mpf) which is plain text and
> > easily edited by hand.
>
> Various others have also mentioned project files and workspaces and
> the like...
>
> Am I the only one that makes *no* use of the various "project things"
> (either in Modelsim or Aldec)? =A0I just have a makefile and use the GUI
> to run the sim (from "their" command-line) and show me the waveforms.
> I guess I don't like to be tied to a tool (as much as I can manage)
> much as I don't like to be tied to a particular silicon vendor (as
> much as I can manage :)
>
> Am I missing something valuable, or is it just different?

I doubt you are missing much of any real use.  I find the GUI will
save me a lot of typing when instantiating modules.  I use the
"generate test bench" feature to build a file with the meat and
potatoes in it and I copy that to the higher level module.

Otherwise if I was practiced in using make files with FPGA tools, I
would be likely be doing that too.

Rick

Article: 146103
Subject: Re: using an FPGA to emulate a vintage computer
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 05 Mar 2010 09:15:48 -0800
Links: << >>  << T >>  << A >>
On Fri, 5 Mar 2010 09:07:31 -0800 (PST), Quadibloc <jsavard@ecn.ab.ca>
wrote:

>On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
>>         No, he's saying that C doesn't really implement an array type, the
>> var[offset] syntax is just syntactic sugar for *(var + offset) which is why
>> things like 3[x] work the same as x[3] in C.
>
>Um, no.
>
>x = y + 3 ;
>
>in a C program will _not_ store in x the value of y plus the contents
>of memory location 3.

Of course not, given that there is dereference operator anywhwere. On
the other hand 

 x = y + *((int*)3);

would do what you want. You need to get that '*' in there.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 146104
Subject: Re: using an FPGA to emulate a vintage computer
From: Ahem A Rivet's Shot <steveo@eircom.net>
Date: Fri, 5 Mar 2010 17:16:35 +0000
Links: << >>  << T >>  << A >>
On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
Quadibloc <jsavard@ecn.ab.ca> wrote:

> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> 
> >         No, he's saying that C doesn't really implement an array type,
> > the var[offset] syntax is just syntactic sugar for *(var + offset)
> > which is why things like 3[x] work the same as x[3] in C.
> 
> Um, no.
> 
> x = y + 3 ;
> 
> in a C program will _not_ store in x the value of y plus the contents
> of memory location 3.

	No but x = *(y + 3) will store in x the contents of the memory
location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
which is what I stated. You missed out the all important * and ()s.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

Article: 146105
Subject: Re: Tabula. (FPGA start up)
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Mar 2010 09:32:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 7:29=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 3/4/2010 12:46 PM, Eric Smith wrote:
>
> > time they ship product. =A0Successful startups usually have something
> > that is *many* times better than the existing products, on some axis
> > almost entirely orthogonal to the prior metrics.
>
> > Eric
>
> Mate,
> Ever wonder if you've been doing this too long? Did you write that last
> phrase with a straight face?
> Cheers, Syms.

Yeah, the funny thing is I understood it AND missed the inside joke
entirely!

Rick

Article: 146106
Subject: Re: Is an inout reg allowed
From: Nathan Bialke <nathan@bialke.com>
Date: Fri, 5 Mar 2010 09:41:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

Out of curiousity, why does your tristate buffer model drive an x
instead of a z?

- Nathan

On Mar 5, 12:28=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 5 Mar 2010 02:22:20 +0000 (UTC), Giorgos Tzampanakis wrote:
> >I've tried to use an inout reg with quartus and it doesn't give a
> >warning. However, I read on the internet that an inout port can
> >only be a wire. Which one is true?
>
> It is unquestionably true that an inout port must be a net
> (wire), and also that you must connect a net to any inout
> port when you instantiate the module. =A0"reg" on either
> side of an inout port is definitely illegal.
>
> If your design uses the inout port in a unidirectional
> manner, it is possible that synthesis might be able to
> do something useful with a reg on one or other side of it.
> However, the resulting illegal Verilog code will never
> work in any simulator. =A0Don't do it.
>
> The classic use of an inout port, to provide a bidi
> tri-state signal, is straightforward. =A0Inside the module
> you need two signals or expressions - probably reg -
> to provide the buffer enable and buffer data. =A0You then
> use a continuous assign to imply the buffer:
>
> =A0 module has_bidi ( inout bidi, ...);
> =A0 =A0 ...
> =A0 =A0 reg bidi_enable;
> =A0 =A0 reg bidi_drive_value;
> =A0 =A0 wire bidi_receive_value;
> =A0 =A0 ...
> =A0 =A0 assign bidi =3D bidi_enable? bidi_drive_value: 1'bx;
> =A0 =A0 assign bidi_receive_value =3D bidi;
> =A0 =A0 ...
> =A0 =A0 .... other logic to use "bidi_receive_value"
> =A0 =A0 .... and generate "bidi_enable" and "bidi_drive_value"
> =A0 endmodule
>
> The second "assign" does nothing more than renaming the port
> for internal use, but it can often be convenient to do that.
> --
> Jonathan Bromley


Article: 146107
Subject: Re: Actel is now the only FPGA vendor with hard-core processor in the
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Mar 2010 09:51:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 3:14 pm, Andy Peters <goo...@latke.net> wrote:
> On Mar 4, 11:56 am, Antti <antti.luk...@googlemail.com> wrote:
>
> > as Xilinx has dropped hard processor IP in the latest families it
> > makes ACTEL the only FPGA vendor whos latest product family does have
> > hard processor IP.
>
> Putting a processor inside an FPGA has proven to us to be a bigger
> PITA than it's worth.

Who exactly is "us"?  Are you with Xilinx, Actel or someone else?


> Consider than instead of V4FX, you can use an S3AN and a standalone
> PPC and you'll pay a whole lot less. Plus the various Freescale PPCs
> have DDR memory and Ethernet and DMA controllers that don't suck, and
> you're not stuck with crappy tools.
>
> Embedding the processor in the FPGA is an interesting idea, but as
> long as Brand X seems to think that the only people who do are the
> types who want to run Linux on an FPGA, it's gonna suck for actual
> embedded use.

The big problem seems to be the problem of too many size combinations
to be practical.  Mixing FPGA, CPU, SRAM and Flash on one chip can't
be all things to all people.  Still, I think there are a few sweet
spots that can be profitable.  A smallish FPGA (~3000 to 5000 LUT4s)
combined with a CM3 in the typical MCU memory combinations is a
powerful device, especially if it is available with a decent dual
CODEC in a package on the smaller side (100 pins or less).  The cost
of low end FPGAs seem to be I/O count driven, so a 5000 LUT4 FPGA can
likely be combined with a CM3 (or maybe a CM0), etc, without
increasing the cost significantly.  I am paying $10 for a 3000 LUT4
FPGA in a 100 TQFP along with a $3 stereo CODEC.  If I could get an
MCU in that package with even just 64 kB of Flash it would allow a
very space constrained product to really have some capabilities... if
they could keep the cost down to $15 at qty 100.

Other than Cypress, no one else seems to see this as a viable market.
I'm still waiting to see if the Cypress PSOC5 is all its cracked up to
be.  The Actel parts are way too expensive from what I've heard and I
think the PSOC5 will be too rich as well.

Rick

Article: 146108
Subject: Re: Display Control Application Using Spartan FPGA
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Mar 2010 09:56:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 10:00=A0am, "Maurice Branson" <trauben...@arcor.de> wrote:
> Hi folks,
>
> I have been introduced to a project where I have to implement a TFT displ=
ay
> controlller on a low-cost FPGA like Spartan-3 or Spartan-6. The controlle=
r
> has to support at least XGA - 1024x768, SXGA - 1280x1024, UXGA - 1600x120=
0
> and WUXGA 1920x1200. I have to chose an appropriate platform now. As I am=
 a
> total newbie in the field of image processing on FPGAs I would ask you fo=
r
> your recommendation about size and type of FPGA, especially in terms of
> logic for video scaling and SRAM memories for frame buffer storage.
>
> Many thanks in advance.
>
> KR, Maurice

Build your controller design and measure the size to pick the part you
need.  Anything else is speculation without a clear understanding of
the design.

BTW, a display controller is not "image processing".  It is just a
display controller.  If you need to do image processing, you need to
describe that in detail to include in your size estimate.

Rick

Article: 146109
Subject: Re: Is an inout reg allowed
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 05 Mar 2010 18:30:20 +0000
Links: << >>  << T >>  << A >>
On Fri, 5 Mar 2010 09:41:25 -0800 (PST), Nathan Bialke wrote:

>Out of curiousity, why does your tristate buffer model drive an x
>instead of a z?

ah, good catch. Runs for cover with tail between legs.

Of course you're right, it should have been

   assign bidi = bidi_enable? bidi_drive_value: 1'bz;

Errrrm, that's what simulators are for, right?
To catch the idiotic typing mistakes?

Thanks!
-- 
Jonathan Bromley

Article: 146110
Subject: Re: Is an inout reg allowed
From: Anssi Saari <as@sci.fi>
Date: Fri, 05 Mar 2010 20:36:16 +0200
Links: << >>  << T >>  << A >>
Nathan Bialke <nathan@bialke.com> writes:

> Hello,
>
> Out of curiousity, why does your tristate buffer model drive an x
> instead of a z?

In my experience this is a fairly common technique to make sure some
other part of the design isn't erroneously reading the x values and
passing them on.

Article: 146111
Subject: Re: using an FPGA to emulate a vintage computer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 5 Mar 2010 18:57:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Mar 4, 1:20?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
(regarding the design of the 360/195 or 360/91)
>> Does anyone know if the information needed to do that still exists?
 
> I suspect it was _very_ closely guarded back in the day, because it
> would have been a matter of very serious concern had the Russians been
> able to make a 360/195 equivalent to top out their RJAD/EC line. So
> I'm thinking more along the line of a design from scratch to match the
> public specifications, working from the 360/91 descriptions in the
> open literature, and adding a cache (which shouldn't be too difficult,
> there being caches on OpenCores). I'm not saying *I* could do stuff
> like that on my very own, but there's a lot out there one could use as
> a starting point.

An important part of the design is the Earle latch, which combines
one level of logic with the latch function.  That is, what is
sometimes called a transparent latch, instead of the edge triggered
D flip-flop commonly available in FPGAs.  There is a lot of literature
on the floating point unit, though I don't know if near enough to
reconstruct one.  For the rest of the processor, I have seen
very little.

I believe that there is some effort towards implementing the
360/30 harware to execute actual 360/30 microcode.  

-- glen

-- glen

Article: 146112
Subject: Re: using an FPGA to emulate a vintage computer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 5 Mar 2010 19:03:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Feb 22, 3:53?pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
 
>> PL/I can be, but doesn't have to be. ?If the arguments of a procedure
>> match the parameters, only the argument address (and possibly a
>> descriptor address for strings structures, and arrays) is passed.
 
> Doesn't PL/I (or, rather, normal implementations thereof) support
> separate compilation of subroutines, just like FORTRAN and COBOL?

I missed the beginning of this thread, but...

Yes, PL/I, at least IBM's implementations, support separate
compilation.  In some cases that requires declaring the argument
types in the calling routine such that appropriate conversion
can be done.   Otherwise, it would be way too hard to use
many routines, with constants having the attributes in which
they are written.  If a routine expected fixed bin(31,0),
for example, you couldn't call it with  1, which would be
fixed dec(1), but would have to use 0000000000000000000000000000001B
instead.  Declaring it as needing fixed bin(31,0), allows the
compiler to do the conversion either at compile or run time.

-- glen

Article: 146113
Subject: Re: FSM in BlockRAM
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 5 Mar 2010 19:10:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
Peter Alfke <alfke@sbcglobal.net> wrote:
(snip)
 
> Peter Alfke, formerly Xilinx Applications (some of you may remember me)

and also notice that you don't post as often as before.

I was not so long ago thinking of asking:

   There is picoblaze (8 bit), and microblaze (32 bit), but no
   nanoblaze (16 bit) or milliblaze (64 bit).  It might even
   be interesting to have a femtoblaze (4 bit) processor.

Maybe not so far off topic, as such processors are, at some level,
complicated state machines.

-- glen

Article: 146114
Subject: Re: using an FPGA to emulate a vintage computer
From: Joe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date: Fri, 05 Mar 2010 12:44:52 -0700
Links: << >>  << T >>  << A >>
Quadibloc <jsavard@ecn.ab.ca> writes:

> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
>>         No, he's saying that C doesn't really implement an array type, the
>> var[offset] syntax is just syntactic sugar for *(var + offset) which is why
>> things like 3[x] work the same as x[3] in C.
>
> Um, no.
>
> x = y + 3 ;
>
> in a C program will _not_ store in x the value of y plus the contents
> of memory location 3.
>
> On a big-endian machine,
>
> long int x[5] ;
> x[0] = 3 ;
> x[1] = 12 ;
> y = x[0] ;
>
> or, on a little-endian machine,
>
> long int x[5] ;
> x[1] = 3 ;
> x[0] = 12 ;
> y = x[1] ;
>
> will not result in zero being stored in y, since a long int variable
> occupies more than one byte in storage, and hence the two assignments
> are being made to overlapping variables.
>
> Yes, C doesn't do _bounds checking_, but that is a far cry from
> "syntactic sugar for variable plus address offset".
I'm not quite sure what the point of your example is, somebody who is
better at programming languages than me would have to evaluate the claim
that C arrays aren't arrays.  But:

#include <stdio.h>
int main()
{
    int a[4];

    printf("a[2] at 0x%8x\n", &(a[2]));
    printf("2[a] at 0x%8x\n", &(2[a]));
    printf("(a+2) is 0x%8x\n", a+2);
    printf("(2+a) is 0x%8x\n", 2+a);

}

[pfeiffer@snowball ~/temp]# ./awry
a[2] at 0xbfff97b8
2[a] at 0xbfff97b8
(a+2) is 0xbfff97b8
(2+a) is 0xbfff97b8
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Article: 146115
Subject: Re: using an FPGA to emulate a vintage computer
From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Fri, 05 Mar 2010 15:12:41 -0500
Links: << >>  << T >>  << A >>

Quadibloc <jsavard@ecn.ab.ca> writes:
> I suspect it was _very_ closely guarded back in the day, because it
> would have been a matter of very serious concern had the Russians been
> able to make a 360/195 equivalent to top out their RJAD/EC line. So
> I'm thinking more along the line of a design from scratch to match the
> public specifications, working from the 360/91 descriptions in the
> open literature, and adding a cache (which shouldn't be too difficult,
> there being caches on OpenCores). I'm not saying *I* could do stuff
> like that on my very own, but there's a lot out there one could use as
> a starting point.

370/195 had some extra instructions & instruction retry added to improve
reliability.

195 had 64 instruction pipeline and imprecise interrupts. 195 didn't
have branch prediction or speculative execution ... so branches (except
for special case loop within pipeline) drained the pipeline.

peak-speed was 10mips ... but most codes ran at half that because of the
frequency of branches draining pipeline.

there was effort to do form of hyperthreading ... looking like
multiprocessor with two instruction streams ... one-bit tag indicating
which i-stream an instruction was associated with; basically same
pipeline, same execution units ... but having two i-streams had better
chance of running at peak thruput. I wasn't directly involved in the
hardware ... just got brought in to look at running multiprocessor
kernel/software for the machine.

195 never got virtual memory.

SJR had 370/195 up thru end of 1978 running MVT.

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

Article: 146116
Subject: Re: FSM in BlockRAM
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 5 Mar 2010 13:19:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 11:10=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Peter Alfke <al...@sbcglobal.net> wrote:
>
> (snip)
>
> > Peter Alfke, formerly Xilinx Applications (some of you may remember me)
>
> and also notice that you don't post as often as before.
>
> I was not so long ago thinking of asking:
>
> =A0 =A0There is picoblaze (8 bit), and microblaze (32 bit), but no
> =A0 =A0nanoblaze (16 bit) or milliblaze (64 bit). =A0It might even
> =A0 =A0be interesting to have a femtoblaze (4 bit) processor.
>
> Maybe not so far off topic, as such processors are, at some level,
> complicated state machines.
>
> -- glen

Blazes...
"Picoblaze" was started by Ken Chapman (still at Xilinx UK) as a
highly optimized design, an app note that works well with 4-input LUTs
and BRAMs. Xilinx has unfortunately always treated it as an
illiigitimate child. (NIH) It lives due to its efficiency, and  due to
Ken's competence, enthusiasm, and perseverance.
"Microblaze" was started by Goran Bilski (originally in Sweden, and
now, after some years in Calif., back again in Sweden.)
It has always been treated as a legitimate Xilinx baby, and Goran has
continuously improved it, and more designers are involved. It grew
from 16 bits to 32 bits. Still a highly optimized design.
I have no idea about plans for 64 bits.

I visit the Xilinx cafeteria once every couple of months to chat with
old friends.
I did repeatedly offer my services as a consultant, even without pay,
but there are no takers.

Peter A.

Article: 146117
Subject: Re: Modelsim PE vs. Aldec Active-HDL (PE)
From: Andy Peters <google@latke.net>
Date: Fri, 5 Mar 2010 13:53:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 10:15=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 5, 5:34=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>
> > Andy Peters <goo...@latke.net> writes:
> > > ModelSim has one project file (the .mpf) which is plain text and
> > > easily edited by hand.
>
> > Various others have also mentioned project files and workspaces and
> > the like...
>
> > Am I the only one that makes *no* use of the various "project things"
> > (either in Modelsim or Aldec)? =A0I just have a makefile and use the GU=
I
> > to run the sim (from "their" command-line) and show me the waveforms.
> > I guess I don't like to be tied to a tool (as much as I can manage)
> > much as I don't like to be tied to a particular silicon vendor (as
> > much as I can manage :)
>
> > Am I missing something valuable, or is it just different?
>
> I doubt you are missing much of any real use. =A0I find the GUI will
> save me a lot of typing when instantiating modules. =A0I use the
> "generate test bench" feature to build a file with the meat and
> potatoes in it and I copy that to the higher level module.
>
> Otherwise if I was practiced in using make files with FPGA tools, I
> would be likely be doing that too.

I don't use any of the Aldec tools that automatically generate test
benches or creating instances and all of that. Yes, I'm an emacs vhdl-
mode user and emacs does a fantabulous job of all of that.

Right now I'm working through the "best" way to set up projects within
the GUI, with an eye towards taking this and generating a Makefile or
a script or something.

It turns out that it is reasonable to create one workspace for an FPGA
project and within this workspace create a "design" for the
subentities and the top level. If you let it use the design name as
the working library for the design, then as long as you "use" the
library in a higher-level source, that source can see those other
libraries.

Now I'm thinking that the usual method of doing:

    u_foo : entity work.foo port map (bar =3D> bar, bletch =3D> bletch);

might be better as:

    u_foo : entity foo.foo port map (bar =3D> bar, bletch =3D> bletch);

The other option is to create a package with a component definition
for foo, and analyze that package into the foo library, so the
instantiation can be:

    u_foo : foo port map (bar =3D> bar, bletch =3D> bletch);

I really don't know which is "better."

-a

Article: 146118
Subject: Re: Actel is now the only FPGA vendor with hard-core processor in the
From: -jg <jim.granville@gmail.com>
Date: Fri, 5 Mar 2010 14:01:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 10:44=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> recognized by Actel also, specially A2F060 must come to low
> price..

Hi Antti,

 Did you get everything finished for ESC ok >

 Speaking of low prices, have you seen price indicators yet on the
SiliconBlue iCE65L01 ?
(other than the 99c/1M pieces) - a 1K-10K price is
more useful :) - and availability timelines ?

-jg


Article: 146119
Subject: Re: using an FPGA to emulate a vintage computer
From: Peter Flass <Peter_Flass@Yahoo.com>
Date: Fri, 05 Mar 2010 17:54:54 -0500
Links: << >>  << T >>  << A >>
Quadibloc wrote:
> On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
> 
>> PL/I can be, but doesn't have to be.  If the arguments of a procedure
>> match the parameters, only the argument address (and possibly a
>> descriptor address for strings structures, and arrays) is passed.
> 
> Doesn't PL/I (or, rather, normal implementations thereof) support
> separate compilation of subroutines, just like FORTRAN and COBOL?
> 

Yes, but the calling sequence among PL/I programs passes information on 
string  lengths, array bounds, etc.  You have to dumb it down to call 
other languages.

For example, you can code:
   a: PROCEDURE( array );
     DECLARE array (*) CHARACTER(*);
     DO i=1 to HBOUND(array);
       DO j=1 TO LENGTH(array(i)); ... END;
       END;

where both the upper limit of "array" is passed along with the string 
length of the element.

Article: 146120
Subject: Re: Display Control Application Using Spartan FPGA
From: Raymund Hofmann <info2@rayed.de>
Date: Fri, 5 Mar 2010 15:06:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On 5 Mrz., 16:00, "Maurice Branson" <trauben...@arcor.de> wrote:
> I have been introduced to a project where I have to implement a TFT display
> controlller on a low-cost FPGA like Spartan-3 or Spartan-6. The controller
> has to support at least XGA - 1024x768, SXGA - 1280x1024, UXGA - 1600x1200
> and WUXGA 1920x1200. I have to chose an appropriate platform now. As I am a
> total newbie in the field of image processing on FPGAs I would ask you for
> your recommendation about size and type of FPGA, especially in terms of
> logic for video scaling and SRAM memories for frame buffer storage.

From my pesonal experience of porting my display contol / scaler ASIC
to a FPGA i would recommend Lattice ECP2/3. I think their timing
Performance is significantly better than Spartan 3 making it not too
difficult to achieve the timing you need for what you say.
But it looks like all this could keep you busy for a few years as a
"total newbie".

Article: 146121
Subject: Re: Laptop for FPGA design?
From: "HT-Lab" <hans64@ht-lab.com>
Date: Sat, 6 Mar 2010 09:52:42 -0000
Links: << >>  << T >>  << A >>

"Adam Górski" <totutousungorskia@malpawp.pl> wrote in message 
news:hmqv2n$5qr$1@atlantis.news.neostrada.pl...
> rickman pisze:
>> On Mar 4, 7:42 am, Adam Górski <totutousungors...@malpawp.pl> wrote:
>>> Pete Fraser pisze:
..>>> Use Remote desktop or similar .
>>> You can have really powerful PC for fpga compilation this way.
>>> If you have inet connection of course.
>>>
>>> Adam
>>
>> Way back when, this software was purchased (PC Anywhere sticks in my
>> mind).  Then I believe MS included it with WinXP, that was how IT used
>> to "fix" my PC.  But I see now it is back to being commercial
>> software.  This this software different somehow than the stuff they
>> had in WinXP or is that gone again?
>
> Remote desktop is included in WinXp Profesional and higher.
> also in Vista Pro and higher.

Just as a warning a number of Flexlm based software is blocking remote desktop 
so you won't be able to run a node-locked license using remote desktop. VNC and 
others work fine,

Hans
www.ht-lab.com


>
> Adam 



Article: 146122
Subject: Re: using an FPGA to emulate a vintage computer
From: Quadibloc <jsavard@ecn.ab.ca>
Date: Sat, 6 Mar 2010 01:58:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 10:16=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> =A0 =A0 =A0 =A0 No but x =3D *(y + 3) will store in x the contents of the=
 memory
> location at 3 + the value of y just as x =3D y[3] will and x =3D 3[y] wil=
l,
> which is what I stated. You missed out the all important * and ()s.

Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.

If C doesn't have "real" arrays, it at least makes a rather good
attempt to simulate them. Unless one's standards are such that FORTRAN
doesn't quite have "real" arrays either, and you need to go to Pascal
for real arrays, there isn't that much to complain about in the case
of C.

John Savard

Article: 146123
Subject: Re: FSM in BlockRAM
From: whygee <yg@yg.yg>
Date: Sat, 06 Mar 2010 10:59:21 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> I did repeatedly offer my services as a consultant, even without pay,
> but there are no takers.
Is it because of "budget restrictions" or because...
you're outside the company's loop now ?
are you an "outcast" already ?

> Peter A.
yg

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

Article: 146124
Subject: Re: using an FPGA to emulate a vintage computer
From: Quadibloc <jsavard@ecn.ab.ca>
Date: Sat, 6 Mar 2010 02:01:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 12:44=A0pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
> Quadibloc <jsav...@ecn.ab.ca> writes:
> > On Feb 26, 4:56=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> >> =A0 =A0 =A0 =A0 No, he's saying that C doesn't really implement an arr=
ay type, the
> >> var[offset] syntax is just syntactic sugar for *(var + offset) which i=
s why
> >> things like 3[x] work the same as x[3] in C.
>
> > Um, no.
>
> > x =3D y + 3 ;
>
> > in a C program will _not_ store in x the value of y plus the contents
> > of memory location 3.
>
> > On a big-endian machine,
>
> > long int x[5] ;
> > x[0] =3D 3 ;
> > x[1] =3D 12 ;
> > y =3D x[0] ;
>
> > or, on a little-endian machine,
>
> > long int x[5] ;
> > x[1] =3D 3 ;
> > x[0] =3D 12 ;
> > y =3D x[1] ;
>
> > will not result in zero being stored in y, since a long int variable
> > occupies more than one byte in storage, and hence the two assignments
> > are being made to overlapping variables.
>
> > Yes, C doesn't do _bounds checking_, but that is a far cry from
> > "syntactic sugar for variable plus address offset".
>
> I'm not quite sure what the point of your example is, somebody who is
> better at programming languages than me would have to evaluate the claim
> that C arrays aren't arrays. =A0But:
>
> #include <stdio.h>
> int main()
> {
> =A0 =A0 int a[4];
>
> =A0 =A0 printf("a[2] at 0x%8x\n", &(a[2]));
> =A0 =A0 printf("2[a] at 0x%8x\n", &(2[a]));
> =A0 =A0 printf("(a+2) is 0x%8x\n", a+2);
> =A0 =A0 printf("(2+a) is 0x%8x\n", 2+a);
>
> }
>
> [pfeiffer@snowball ~/temp]# ./awry
> a[2] at 0xbfff97b8
> 2[a] at 0xbfff97b8
> (a+2) is 0xbfff97b8
> (2+a) is 0xbfff97b8

The 2[a] syntax actually *works* in C the way it was described? I am
astonished. I would expect it to yield the contents of the memory
location a+&2 assuming that &2 can be persuaded to yield up the
location where the value of the constant "2" is stored.

Evidently there is some discrepancy between C and FORTRAN.

John Savard



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