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 161475

Article: 161475
Subject: Re: Tiny CPUs for Slow Logic
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Tue, 8 Oct 2019 21:04:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, October 8, 2019 at 11:24:28 PM UTC-4, oldben wrote:
> On 3/18/2019 6:13 PM, gnuarm.deletethisbit@gmail.com wrote:
> > Most of us have implemented small processors for logic operations that =
don't need to happen at high speed.  Simple CPUs can be built into an FPGA =
using a very small footprint much like the ALU blocks.  There are stack bas=
ed processors that are very small, smaller than even a few kB of memory.
> >=20
> > If they were easily programmable in something other than C would anyone=
 be interested?  Or is a C compiler mandatory even for processors running v=
ery small programs?
> >=20
> > I am picturing this not terribly unlike the sequencer I used many years=
 ago on an I/O board for an array processor which had it's own assembler.  =
It was very simple and easy to use, but very much not a high level language=
.  This would have a language that was high level, just not C rather someth=
ing extensible and simple to use and potentially interactive.
> >=20
> > Rick C.
> >=20
> Where do find the memory for the program and data?
> On the FPGA, external or floating on a cloud?
> Oldben

This is a bit of an old thread.  I don't recall having anything in mind.  I=
 started out just trying to consider what might be useful, but I really don=
't recall.  All the CPUs I've designed had local memory. =20

--=20

  Rick C.

  - Get 2,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

Article: 161476
Subject: Re: Tiny CPUs for Slow Logic
From: jim.brakefield@ieee.org
Date: Wed, 16 Oct 2019 09:14:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, October 8, 2019 at 11:04:15 PM UTC-5, Rick C wrote:
> On Tuesday, October 8, 2019 at 11:24:28 PM UTC-4, oldben wrote:
> > On 3/18/2019 6:13 PM, gnuarm.deletethisbit@gmail.com wrote:
> > > Most of us have implemented small processors for logic operations tha=
t don't need to happen at high speed.  Simple CPUs can be built into an FPG=
A using a very small footprint much like the ALU blocks.  There are stack b=
ased processors that are very small, smaller than even a few kB of memory.
> > >=20
> > > If they were easily programmable in something other than C would anyo=
ne be interested?  Or is a C compiler mandatory even for processors running=
 very small programs?
> > >=20
> > > I am picturing this not terribly unlike the sequencer I used many yea=
rs ago on an I/O board for an array processor which had it's own assembler.=
  It was very simple and easy to use, but very much not a high level langua=
ge.  This would have a language that was high level, just not C rather some=
thing extensible and simple to use and potentially interactive.
> > >=20
> > > Rick C.
> > >=20
> > Where do find the memory for the program and data?
> > On the FPGA, external or floating on a cloud?
> > Oldben
>=20
> This is a bit of an old thread.  I don't recall having anything in mind. =
 I started out just trying to consider what might be useful, but I really d=
on't recall.  All the CPUs I've designed had local memory. =20
>=20
> --=20
>=20
>   Rick C.
>=20
>   - Get 2,000 miles of free Supercharging
>   - Tesla referral code - https://ts.la/richard11209

Missed this thread back in March.
My interest was/is in treating EDIF as the machine language.
If you can simulate all the logic in under, say, 50 usec.
that's faster than human reaction times and suitable for controllers.
So at 200MHZ that's 10K instructions, or ~10K logic gates per cycle.

So an FPGA uP design using one block RAM and under 200 LUTs is sufficient.
Duplicate the uP if you have more logic than this.  200 LUTs is much less t=
han $1.

Jim Brakefield


Article: 161477
Subject: EDIF as machine language
From: HT-Lab <hans64@htminuslab.com>
Date: Fri, 25 Oct 2019 10:50:44 +0100
Links: << >>  << T >>  << A >>
On 16/10/2019 17:14, jim.brakefield@ieee.org wrote:
> On Tuesday, October 8, 2019 at 11:04:15 PM UTC-5, Rick C wrote:
>> On Tuesday, October 8, 2019 at 11:24:28 PM UTC-4, oldben wrote:
..
> 
> Missed this thread back in March.
> My interest was/is in treating EDIF as the machine language.
> If you can simulate all the logic in under, say, 50 usec.
> that's faster than human reaction times and suitable for controllers.
> So at 200MHZ that's 10K instructions, or ~10K logic gates per cycle.
> 
> So an FPGA uP design using one block RAM and under 200 LUTs is sufficient.
> Duplicate the uP if you have more logic than this.  200 LUTs is much less than $1.
> 
> Jim Brakefield
> 

Are you trying to emulate a small FPGA on a microcontroller? This sounds 
like an overly complicated especially as an EDIF is normally full of 
complex (and not always fully documented) primitives which will be a 
real pain to simulate.

Perhaps I am wrong and this is a brilliant idea? I would be interested 
to hear some more,

Regards,
Hans
www.ht-lab.com

Article: 161478
Subject: Re: EDIF as machine language
From: Jon Elson <elson@pico-systems.com>
Date: Fri, 25 Oct 2019 15:30:19 -0500
Links: << >>  << T >>  << A >>
On Fri, 25 Oct 2019 10:50:44 +0100, HT-Lab wrote:


> Are you trying to emulate a small FPGA on a microcontroller?

Gee, emulating a small CPU on an FPGA might be a lot better way to go.
I have used smallish FPGAs to do some jobs where typically a 
microcontroller would be used, and they worked pretty well.

I've also used Xilinx CPLDs from the 9500 and CoolRunner II family for 
simple small logic needs, and they have done quite well.  These cost just 
a couple $ in small quantity.  The smallest, 9536XL is just over $1 in 
single quantity at Digi-Key.

Jon

Article: 161479
Subject: Re: EDIF as machine language
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Fri, 25 Oct 2019 14:17:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 25, 2019 at 4:30:27 PM UTC-4, Jon Elson wrote:
> On Fri, 25 Oct 2019 10:50:44 +0100, HT-Lab wrote:
> 
> 
> > Are you trying to emulate a small FPGA on a microcontroller?
> 
> Gee, emulating a small CPU on an FPGA might be a lot better way to go.
> I have used smallish FPGAs to do some jobs where typically a 
> microcontroller would be used, and they worked pretty well.
> 
> I've also used Xilinx CPLDs from the 9500 and CoolRunner II family for 
> simple small logic needs, and they have done quite well.  These cost just 
> a couple $ in small quantity.  The smallest, 9536XL is just over $1 in 
> single quantity at Digi-Key.

When it comes to the Xilinx CoolRunner II parts, only the small ones are cheap.  The larger ones get very expensive for what they can do. 

-- 

  Rick C.

  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

Article: 161480
Subject: Re: EDIF as machine language
From: jim.brakefield@ieee.org
Date: Fri, 25 Oct 2019 15:08:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 25, 2019 at 4:50:49 AM UTC-5, HT-Lab wrote:
> On 16/10/2019 17:14, jim.brakefield@ieee.org wrote:
> > On Tuesday, October 8, 2019 at 11:04:15 PM UTC-5, Rick C wrote:
> >> On Tuesday, October 8, 2019 at 11:24:28 PM UTC-4, oldben wrote:
> ..
> >=20
> > Missed this thread back in March.
> > My interest was/is in treating EDIF as the machine language.
> > If you can simulate all the logic in under, say, 50 usec.
> > that's faster than human reaction times and suitable for controllers.
> > So at 200MHZ that's 10K instructions, or ~10K logic gates per cycle.
> >=20
> > So an FPGA uP design using one block RAM and under 200 LUTs is sufficie=
nt.
> > Duplicate the uP if you have more logic than this.  200 LUTs is much le=
ss than $1.
> >=20
> > Jim Brakefield
> >=20
>=20
> Are you trying to emulate a small FPGA on a microcontroller? This sounds=
=20
> like an overly complicated especially as an EDIF is normally full of=20
> complex (and not always fully documented) primitives which will be a=20
> real pain to simulate.
>=20
> Perhaps I am wrong and this is a brilliant idea? I would be interested=20
> to hear some more,
>=20
> Regards,
> Hans
> www.ht-lab.com

My experience with EDIF was the output of VHDL/Verilog compilers for FPGAs.=
  EDIF output was lots of simple gates and black boxes for block RAM.  The =
FPGA vendors then write a mapper, placer and router into their silicon.  So=
 for the application with low duty cycle gates it's more efficient to emula=
te the gates via a small CPU and its single block RAM.  For a while Xilinx =
supported a similar approach via HDL to "C" and run on their ARM or PPC har=
d cores.
Now EDIF is just a bunch of black boxes, simple gates or as complex as desi=
red, wired together.
There are applications, such as industrial control that run the control log=
ic at kilohertz rates.  Very low duty cycle for FPGA LUTs.  So one is tradi=
ng speed for density.
As a side note, ASIC logic simulators have some of the same issues, however=
, one wants to run the ASIC simulation as fast as possible, essentially in =
the megahertz range.

In summary, there are a range of applications that do logic "simulation" ov=
er a wide range of cycle rates; from millisecond human reaction times all t=
he way up to "as fast as possible".  Would argue that there needs to be too=
l chains that support the six order of magnitude range of logic cycle rates=
.  In particular, not much attention to the low end of cycle rates, which c=
urrently is supported by real-time embedded tools.

Jim Brakefield



Article: 161481
Subject: Re: EDIF as machine language
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Fri, 25 Oct 2019 16:32:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 25, 2019 at 6:09:03 PM UTC-4, jim.br...@ieee.org wrote:
> On Friday, October 25, 2019 at 4:50:49 AM UTC-5, HT-Lab wrote:
> > On 16/10/2019 17:14, jim.brakefield@ieee.org wrote:
> > > On Tuesday, October 8, 2019 at 11:04:15 PM UTC-5, Rick C wrote:
> > >> On Tuesday, October 8, 2019 at 11:24:28 PM UTC-4, oldben wrote:
> > ..
> > >=20
> > > Missed this thread back in March.
> > > My interest was/is in treating EDIF as the machine language.
> > > If you can simulate all the logic in under, say, 50 usec.
> > > that's faster than human reaction times and suitable for controllers.
> > > So at 200MHZ that's 10K instructions, or ~10K logic gates per cycle.
> > >=20
> > > So an FPGA uP design using one block RAM and under 200 LUTs is suffic=
ient.
> > > Duplicate the uP if you have more logic than this.  200 LUTs is much =
less than $1.
> > >=20
> > > Jim Brakefield
> > >=20
> >=20
> > Are you trying to emulate a small FPGA on a microcontroller? This sound=
s=20
> > like an overly complicated especially as an EDIF is normally full of=20
> > complex (and not always fully documented) primitives which will be a=20
> > real pain to simulate.
> >=20
> > Perhaps I am wrong and this is a brilliant idea? I would be interested=
=20
> > to hear some more,
> >=20
> > Regards,
> > Hans
> > www.ht-lab.com
>=20
> My experience with EDIF was the output of VHDL/Verilog compilers for FPGA=
s.  EDIF output was lots of simple gates and black boxes for block RAM.  Th=
e FPGA vendors then write a mapper, placer and router into their silicon.  =
So for the application with low duty cycle gates it's more efficient to emu=
late the gates via a small CPU and its single block RAM.  For a while Xilin=
x supported a similar approach via HDL to "C" and run on their ARM or PPC h=
ard cores.
> Now EDIF is just a bunch of black boxes, simple gates or as complex as de=
sired, wired together.
> There are applications, such as industrial control that run the control l=
ogic at kilohertz rates.  Very low duty cycle for FPGA LUTs.  So one is tra=
ding speed for density.
> As a side note, ASIC logic simulators have some of the same issues, howev=
er, one wants to run the ASIC simulation as fast as possible, essentially i=
n the megahertz range.
>=20
> In summary, there are a range of applications that do logic "simulation" =
over a wide range of cycle rates; from millisecond human reaction times all=
 the way up to "as fast as possible".  Would argue that there needs to be t=
ool chains that support the six order of magnitude range of logic cycle rat=
es.  In particular, not much attention to the low end of cycle rates, which=
 currently is supported by real-time embedded tools.
>=20
> Jim Brakefield

I get what you are saying.  But why would anyone first design something in =
HDL only to have it compiled and then simulated in a CPU?  Why would such l=
ow bandwidth processing not be coded in a sequential language conventionall=
y used on CPUs, like C?  Skip the hassle of compiling in an HDL tool and th=
en importing to a simulator running on the target CPU?  Where is the advant=
age exactly?=20

I will say that if you use the language output from the place and route too=
ls you will get something more like LUTs which are likely to simulate faste=
r than individual gates.  Remember that unless you have some very tiny amou=
nt of logic that can be implemented in some sort of immense look up table, =
every connection between gates is a signal that will need to be scheduled t=
o "run" when the inputs change.  Fewer entities means less scheduling... ma=
ybe.=20

--=20

  Rick C.

  + Get 1,000 miles of free Supercharging
  + Tesla referral code - https://ts.la/richard11209

Article: 161482
Subject: Re: EDIF as machine language
From: jim.brakefield@ieee.org
Date: Fri, 25 Oct 2019 18:05:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 25, 2019 at 6:32:28 PM UTC-5, Rick C wrote:
> On Friday, October 25, 2019 at 6:09:03 PM UTC-4, jim.br...@ieee.org wrote=
:
> > On Friday, October 25, 2019 at 4:50:49 AM UTC-5, HT-Lab wrote:
> > > On 16/10/2019 17:14, jim.brakefield@ieee.org wrote:
> > > > On Tuesday, October 8, 2019 at 11:04:15 PM UTC-5, Rick C wrote:
> > > >> On Tuesday, October 8, 2019 at 11:24:28 PM UTC-4, oldben wrote:
> > > ..
> > > >=20
> > > > Missed this thread back in March.
> > > > My interest was/is in treating EDIF as the machine language.
> > > > If you can simulate all the logic in under, say, 50 usec.
> > > > that's faster than human reaction times and suitable for controller=
s.
> > > > So at 200MHZ that's 10K instructions, or ~10K logic gates per cycle=
.
> > > >=20
> > > > So an FPGA uP design using one block RAM and under 200 LUTs is suff=
icient.
> > > > Duplicate the uP if you have more logic than this.  200 LUTs is muc=
h less than $1.
> > > >=20
> > > > Jim Brakefield
> > > >=20
> > >=20
> > > Are you trying to emulate a small FPGA on a microcontroller? This sou=
nds=20
> > > like an overly complicated especially as an EDIF is normally full of=
=20
> > > complex (and not always fully documented) primitives which will be a=
=20
> > > real pain to simulate.
> > >=20
> > > Perhaps I am wrong and this is a brilliant idea? I would be intereste=
d=20
> > > to hear some more,
> > >=20
> > > Regards,
> > > Hans
> > > www.ht-lab.com
> >=20
> > My experience with EDIF was the output of VHDL/Verilog compilers for FP=
GAs.  EDIF output was lots of simple gates and black boxes for block RAM.  =
The FPGA vendors then write a mapper, placer and router into their silicon.=
  So for the application with low duty cycle gates it's more efficient to e=
mulate the gates via a small CPU and its single block RAM.  For a while Xil=
inx supported a similar approach via HDL to "C" and run on their ARM or PPC=
 hard cores.
> > Now EDIF is just a bunch of black boxes, simple gates or as complex as =
desired, wired together.
> > There are applications, such as industrial control that run the control=
 logic at kilohertz rates.  Very low duty cycle for FPGA LUTs.  So one is t=
rading speed for density.
> > As a side note, ASIC logic simulators have some of the same issues, how=
ever, one wants to run the ASIC simulation as fast as possible, essentially=
 in the megahertz range.
> >=20
> > In summary, there are a range of applications that do logic "simulation=
" over a wide range of cycle rates; from millisecond human reaction times a=
ll the way up to "as fast as possible".  Would argue that there needs to be=
 tool chains that support the six order of magnitude range of logic cycle r=
ates.  In particular, not much attention to the low end of cycle rates, whi=
ch currently is supported by real-time embedded tools.
> >=20
> > Jim Brakefield
>=20
> I get what you are saying.  But why would anyone first design something i=
n HDL only to have it compiled and then simulated in a CPU?  Why would such=
 low bandwidth processing not be coded in a sequential language conventiona=
lly used on CPUs, like C?  Skip the hassle of compiling in an HDL tool and =
then importing to a simulator running on the target CPU?  Where is the adva=
ntage exactly?=20
>=20
> I will say that if you use the language output from the place and route t=
ools you will get something more like LUTs which are likely to simulate fas=
ter than individual gates.  Remember that unless you have some very tiny am=
ount of logic that can be implemented in some sort of immense look up table=
, every connection between gates is a signal that will need to be scheduled=
 to "run" when the inputs change.  Fewer entities means less scheduling... =
maybe.=20
>=20
> --=20
>=20
>   Rick C.
>=20
>   + Get 1,000 miles of free Supercharging
>   + Tesla referral code - https://ts.la/richard11209

|>But why would anyone first design something in HDL only to have it compil=
ed and then simulated in a CPU?
Was thinking of EDIF as a universal assembly language.
Parallel processing via multiple interconnected processors.
Hard real-time: Easy to determine worst case delay =3D # of instructions ex=
ecuted per cycle.
Very few processors are under $0.10.

|>every connection between gates is a signal that will need to be scheduled=
 to "run" when the inputs change
Was thinking in terms of synchronous simulation where each "gate" is evalua=
ted only once per clock cycle. 

Article: 161483
Subject: Re: EDIF as machine language
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Fri, 25 Oct 2019 18:36:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 25, 2019 at 9:05:12 PM UTC-4, jim.br...@ieee.org wrote:
> On Friday, October 25, 2019 at 6:32:28 PM UTC-5, Rick C wrote:
> > On Friday, October 25, 2019 at 6:09:03 PM UTC-4, jim.br...@ieee.org wro=
te:
> > > On Friday, October 25, 2019 at 4:50:49 AM UTC-5, HT-Lab wrote:
> > > > On 16/10/2019 17:14, jim.brakefield@ieee.org wrote:
> > > > > On Tuesday, October 8, 2019 at 11:04:15 PM UTC-5, Rick C wrote:
> > > > >> On Tuesday, October 8, 2019 at 11:24:28 PM UTC-4, oldben wrote:
> > > > ..
> > > > >=20
> > > > > Missed this thread back in March.
> > > > > My interest was/is in treating EDIF as the machine language.
> > > > > If you can simulate all the logic in under, say, 50 usec.
> > > > > that's faster than human reaction times and suitable for controll=
ers.
> > > > > So at 200MHZ that's 10K instructions, or ~10K logic gates per cyc=
le.
> > > > >=20
> > > > > So an FPGA uP design using one block RAM and under 200 LUTs is su=
fficient.
> > > > > Duplicate the uP if you have more logic than this.  200 LUTs is m=
uch less than $1.
> > > > >=20
> > > > > Jim Brakefield
> > > > >=20
> > > >=20
> > > > Are you trying to emulate a small FPGA on a microcontroller? This s=
ounds=20
> > > > like an overly complicated especially as an EDIF is normally full o=
f=20
> > > > complex (and not always fully documented) primitives which will be =
a=20
> > > > real pain to simulate.
> > > >=20
> > > > Perhaps I am wrong and this is a brilliant idea? I would be interes=
ted=20
> > > > to hear some more,
> > > >=20
> > > > Regards,
> > > > Hans
> > > > www.ht-lab.com
> > >=20
> > > My experience with EDIF was the output of VHDL/Verilog compilers for =
FPGAs.  EDIF output was lots of simple gates and black boxes for block RAM.=
  The FPGA vendors then write a mapper, placer and router into their silico=
n.  So for the application with low duty cycle gates it's more efficient to=
 emulate the gates via a small CPU and its single block RAM.  For a while X=
ilinx supported a similar approach via HDL to "C" and run on their ARM or P=
PC hard cores.
> > > Now EDIF is just a bunch of black boxes, simple gates or as complex a=
s desired, wired together.
> > > There are applications, such as industrial control that run the contr=
ol logic at kilohertz rates.  Very low duty cycle for FPGA LUTs.  So one is=
 trading speed for density.
> > > As a side note, ASIC logic simulators have some of the same issues, h=
owever, one wants to run the ASIC simulation as fast as possible, essential=
ly in the megahertz range.
> > >=20
> > > In summary, there are a range of applications that do logic "simulati=
on" over a wide range of cycle rates; from millisecond human reaction times=
 all the way up to "as fast as possible".  Would argue that there needs to =
be tool chains that support the six order of magnitude range of logic cycle=
 rates.  In particular, not much attention to the low end of cycle rates, w=
hich currently is supported by real-time embedded tools.
> > >=20
> > > Jim Brakefield
> >=20
> > I get what you are saying.  But why would anyone first design something=
 in HDL only to have it compiled and then simulated in a CPU?  Why would su=
ch low bandwidth processing not be coded in a sequential language conventio=
nally used on CPUs, like C?  Skip the hassle of compiling in an HDL tool an=
d then importing to a simulator running on the target CPU?  Where is the ad=
vantage exactly?=20
> >=20
> > I will say that if you use the language output from the place and route=
 tools you will get something more like LUTs which are likely to simulate f=
aster than individual gates.  Remember that unless you have some very tiny =
amount of logic that can be implemented in some sort of immense look up tab=
le, every connection between gates is a signal that will need to be schedul=
ed to "run" when the inputs change.  Fewer entities means less scheduling..=
. maybe.=20
> >=20
> > --=20
> >=20
> >   Rick C.
> >=20
> >   + Get 1,000 miles of free Supercharging
> >   + Tesla referral code - https://ts.la/richard11209
>=20
> |>But why would anyone first design something in HDL only to have it comp=
iled and then simulated in a CPU?
> Was thinking of EDIF as a universal assembly language.
> Parallel processing via multiple interconnected processors.
> Hard real-time: Easy to determine worst case delay =3D # of instructions =
executed per cycle.
> Very few processors are under $0.10.
>=20
> |>every connection between gates is a signal that will need to be schedul=
ed to "run" when the inputs change
> Was thinking in terms of synchronous simulation where each "gate" is eval=
uated only once per clock cycle.

I'm pretty sure that does not exist.  Race conditions exist in simulations =
if you interconnect gates as you are describing.  VHDL handles this by intr=
oducing delta delays which are treated like small delays, but no time ticks=
 off the clock, just deltas.  Then each gate can have a delta delay associa=
ted with it.  This in turn requires that each signal (gate output) be evalu=
ated each time any of the inputs change.  Because of the unit delays there =
can be multiple changes at different delta delays. =20

Otherwise the input to a FF much be written as an expression with defined r=
ules of order of evaluation. =20

Or do you have a method of assuring the consistency of evaluation of signal=
s through gates?=20

--=20

  Rick C.

  -- Get 1,000 miles of free Supercharging
  -- Tesla referral code - https://ts.la/richard11209

Article: 161484
Subject: Lattice MachXO2/XO3/XO3D vs ECP5
From: Brane2 <brankob@avtomatika.com>
Date: Thu, 7 Nov 2019 04:20:13 -0800 (PST)
Links: << >>  << T >>  << A >>
Can anyone shed some light on why are XO2/3 chips so expenisive compared to ECP5 ?

XO2/3 is supposed to be middle-to-low end of their product lines, but simple 
6900 LUT XO3 is significantly more expensive than 12kLUT ECP5.

What gives ?


Article: 161485
Subject: Re: Lattice XO3D New
From: Brane2 <brankob@avtomatika.com>
Date: Thu, 7 Nov 2019 05:10:31 -0800 (PST)
Links: << >>  << T >>  << A >>
I like other aspect of it -crypto.

As in, one could make the deisgns that allow the code to be downloaded at c=
ustomers premises without violating security or owner's IP.

But for some reason all that XO2/3/3D stuff seems  expensive, compared to E=
CP5...

Also, they seem to overcharge and underutilize FLASH on board.

If all that config flash is on the chip, whyis it so awkward to use it for =
user data ? I think these things are doone at 28nm, which should sout the F=
LASH just fine. Why is it not accessible through, say, 64-bit bus or as som=
e kinf of FLASH-block ( similar to RAM-blocks) ?

And, as you've noticed, it would be nice to see those things in LQFP-144...

At reasonable price.



Article: 161486
Subject: Re: Lattice MachXO2/XO3/XO3D vs ECP5
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Thu, 7 Nov 2019 07:40:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, November 7, 2019 at 7:20:16 AM UTC-5, Brane2 wrote:
> Can anyone shed some light on why are XO2/3 chips so expenisive compared =
to ECP5 ?
>=20
> XO2/3 is supposed to be middle-to-low end of their product lines, but sim=
ple=20
> 6900 LUT XO3 is significantly more expensive than 12kLUT ECP5.
>=20
> What gives ?

ECP5 is a RAM based family much like the Xilinx parts.=20

The XO, XO2, XO3, XP2 device families are all flash based.  I don't know th=
e details of how their fabrication is different from the RAM based ECP fami=
lies, but the flash does take up die space if nothing else.  I'm sure the f=
lash capabilities aren't available on the smallest feature size processes. =
=20

Lattice also makes the Silicon Blue derived iCE40 families which are non-vo=
latile as in one time writable ROM based. =20

--=20

  Rick C.

  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

Article: 161487
Subject: Re: Lattice XO3D New
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Thu, 7 Nov 2019 07:45:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, November 7, 2019 at 8:10:35 AM UTC-5, Brane2 wrote:
> I like other aspect of it -crypto.
>=20
> As in, one could make the deisgns that allow the code to be downloaded at=
 customers premises without violating security or owner's IP.
>=20
> But for some reason all that XO2/3/3D stuff seems  expensive, compared to=
 ECP5...
>=20
> Also, they seem to overcharge and underutilize FLASH on board.
>=20
> If all that config flash is on the chip, whyis it so awkward to use it fo=
r user data ? I think these things are doone at 28nm, which should sout the=
 FLASH just fine. Why is it not accessible through, say, 64-bit bus or as s=
ome kinf of FLASH-block ( similar to RAM-blocks) ?
>=20
> And, as you've noticed, it would be nice to see those things in LQFP-144.=
..
>=20
> At reasonable price.

Please don't say QFP-144.  That is the package so often available for non-B=
GA packaging because of the I/O count I'm sure.  It's a monster and won't e=
ven fit on the boards I make.  A small 0.5 mm QFN is the sort of packaging =
I think is needed more in the FPGA world. =20

I don't build products with 64 bit external buses or wide memory interfaces=
.  I need FPGAs that can fit in sockets that otherwise would be suitable fo=
r MCUs. =20

--=20

  Rick C.

  + Get 1,000 miles of free Supercharging
  + Tesla referral code - https://ts.la/richard11209

Article: 161488
Subject: Re: Lattice MachXO2/XO3/XO3D vs ECP5
From: Brane2 <brankob@avtomatika.com>
Date: Thu, 7 Nov 2019 22:17:33 -0800 (PST)
Links: << >>  << T >>  << A >>
XO families only contain FLASH, they are not flash absed AFAIK.

That is, during the initialisation FLASH still gets internally copied to SRAM.

If the FLASH onboard is the reason for the price, why is 7kLUT XO2 or XO3 so much more expensive than 12kLUT ECP + much bigger SPI FLASH ?


Article: 161489
Subject: FPGA config sizes
From: John Larkin <jlarkin@highland_atwork_technology.com>
Date: Fri, 08 Nov 2019 11:08:54 -0800
Links: << >>  << T >>  << A >>


We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application? 

I think we could enable compression too.

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 161490
Subject: Re: FPGA config sizes
From: Gerhard Hoffmann <dk4xp@arcor.de>
Date: Fri, 8 Nov 2019 20:13:11 +0100
Links: << >>  << T >>  << A >>
Am 08.11.19 um 20:08 schrieb John Larkin:
> 
> 
> We're planning a new universal boot loader for a family of ST
> processors. The uP would host the loader in a bit of local flash and
> read an outboard serial flash to get the specific application code and
> one or more FPGA configurations.
> 
> So, how many config bits might there be for a modern mid-range FPGA
> doing a moderately complex application?
> 
> I think we could enable compression too.
> 
> Please consider this a PHB type question. I don't do FPGA development
> myself, past whiteboarding.
> 

The size of the programming file is in the data sheet. It is constant
and does not depend on the implemented circuitry.

Newer FPGAs may allow to program only some sectors of the chip.

regards, Gerhard

Article: 161491
Subject: Re: FPGA config sizes
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Fri, 8 Nov 2019 11:22:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:
> We're planning a new universal boot loader for a family of ST
> processors. The uP would host the loader in a bit of local flash and
> read an outboard serial flash to get the specific application code and
> one or more FPGA configurations.
> 
> So, how many config bits might there be for a modern mid-range FPGA
> doing a moderately complex application? 
> 
> I think we could enable compression too.
> 
> Please consider this a PHB type question. I don't do FPGA development
> myself, past whiteboarding.

Anyone know what a "PHB type question" is? 

-- 

  Rick C.

  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

Article: 161492
Subject: Re: FPGA config sizes
From: Andy Bennet <andyb@andy.com>
Date: Fri, 8 Nov 2019 20:33:07 +0000
Links: << >>  << T >>  << A >>
On 08/11/2019 19:08, John Larkin wrote:
> 
> 
> We're planning a new universal boot loader for a family of ST
> processors. The uP would host the loader in a bit of local flash and
> read an outboard serial flash to get the specific application code and
> one or more FPGA configurations.
> 
> So, how many config bits might there be for a modern mid-range FPGA
> doing a moderately complex application?
> 
> I think we could enable compression too.
> 
> Please consider this a PHB type question. I don't do FPGA development
> myself, past whiteboarding.
> 

The uncompressed FPGA configuration file size does not change with the 
device utilization.
You need to look at the data sheet for the particular device.
Obviously the compressed file size will be variable - with anything from 
0% to near 100% compression ratio dependent on content and compression 
algorithm.

Article: 161493
Subject: Re: FPGA config sizes
From: jim.brakefield@ieee.org
Date: Fri, 8 Nov 2019 12:37:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, November 8, 2019 at 1:09:04 PM UTC-6, John Larkin wrote:
> We're planning a new universal boot loader for a family of ST
> processors. The uP would host the loader in a bit of local flash and
> read an outboard serial flash to get the specific application code and
> one or more FPGA configurations.
> 
> So, how many config bits might there be for a modern mid-range FPGA
> doing a moderately complex application? 
> 
> I think we could enable compression too.
> 
> Please consider this a PHB type question. I don't do FPGA development
> myself, past whiteboarding.
> 
> -- 
> 
> John Larkin         Highland Technology, Inc
> picosecond timing   precision measurement 
> 
> jlarkin att highlandtechnology dott com
> http://www.highlandtechnology.com

There's a general trend of about 60-80 bits per LUT input (can go higher).
4LUT has ~4-6 inputs, 6LUT or ALM 6-8 inputs.  Count the number of LUTs in the part and multiply.  Some go as high as 400M+ configuration bits.

Jim Brakefield

Article: 161494
Subject: Re: FPGA config sizes
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Fri, 08 Nov 2019 23:46:22 +0100
Links: << >>  << T >>  << A >>
On 2019-11-08 Rick C wrote in comp.arch.fpga:
> On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:
>> 
>> Please consider this a PHB type question. I don't do FPGA development
>> myself, past whiteboarding.
>
> Anyone know what a "PHB type question" is? 

https://dilbert.com/search_results?terms=phb

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Corry's Law:
	Paper is always strongest at the perforations.

Article: 161495
Subject: Re: FPGA config sizes
From: Rick C <gnuarm.deletethisbit@gmail.com>
Date: Fri, 8 Nov 2019 15:12:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, November 8, 2019 at 5:48:04 PM UTC-5, Stef wrote:
> On 2019-11-08 Rick C wrote in comp.arch.fpga:
> > On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:
> >> 
> >> Please consider this a PHB type question. I don't do FPGA development
> >> myself, past whiteboarding.
> >
> > Anyone know what a "PHB type question" is? 
> 
> https://dilbert.com/search_results?terms=phb

Yeah, someone explained in the other group.  A bit obscure, methinks. 

-- 

  Rick C.

  + Get 1,000 miles of free Supercharging
  + Tesla referral code - https://ts.la/richard11209

Article: 161496
Subject: Re: FPGA config sizes
From: Michael Kellett <mk@mkesc.co.uk>
Date: Sat, 9 Nov 2019 09:49:45 +0000
Links: << >>  << T >>  << A >>
On 08/11/2019 19:08, John Larkin wrote:
> 
> 
> We're planning a new universal boot loader for a family of ST
> processors. The uP would host the loader in a bit of local flash and
> read an outboard serial flash to get the specific application code and
> one or more FPGA configurations.
> 
> So, how many config bits might there be for a modern mid-range FPGA
> doing a moderately complex application?
> 
> I think we could enable compression too.
> 
> Please consider this a PHB type question. I don't do FPGA development
> myself, past whiteboarding.
> 
 From Lattice ECP5 sysCONFIG Usage Guide FPGA-TN-02039.

LFE5-45 - 8.86Mb


 From Xilinx UG470
Xilinx Artix 35T and 50T need the same 17.536 Mb

MK

Article: 161497
Subject: Re: FPGA config sizes
From: TTman <kraken.sankey@gmail.com>
Date: Sat, 9 Nov 2019 11:15:56 +0000
Links: << >>  << T >>  << A >>
On 09/11/2019 09:49, Michael Kellett wrote:
> On 08/11/2019 19:08, John Larkin wrote:
>>
>>
>> We're planning a new universal boot loader for a family of ST
>> processors. The uP would host the loader in a bit of local flash and
>> read an outboard serial flash to get the specific application code and
>> one or more FPGA configurations.
>>
>> So, how many config bits might there be for a modern mid-range FPGA
>> doing a moderately complex application?
>>
>> I think we could enable compression too.
>>
>> Please consider this a PHB type question. I don't do FPGA development
>> myself, past whiteboarding.
>>
>  From Lattice ECP5 sysCONFIG Usage Guide FPGA-TN-02039.
> 
> LFE5-45 - 8.86Mb
> 
> 
>  From Xilinx UG470
> Xilinx Artix 35T and 50T need the same 17.536 Mb
> 
> MK
Why complicate things with memory soooo cheap ??? Just store raw data...

Article: 161498
Subject: Re: FPGA config sizes
From: jlarkin@highlandsniptechnology.com
Date: Sat, 09 Nov 2019 09:38:31 -0800
Links: << >>  << T >>  << A >>
On Sat, 9 Nov 2019 11:15:56 +0000, TTman <kraken.sankey@gmail.com>
wrote:

>On 09/11/2019 09:49, Michael Kellett wrote:
>> On 08/11/2019 19:08, John Larkin wrote:
>>>
>>>
>>> We're planning a new universal boot loader for a family of ST
>>> processors. The uP would host the loader in a bit of local flash and
>>> read an outboard serial flash to get the specific application code and
>>> one or more FPGA configurations.
>>>
>>> So, how many config bits might there be for a modern mid-range FPGA
>>> doing a moderately complex application?
>>>
>>> I think we could enable compression too.
>>>
>>> Please consider this a PHB type question. I don't do FPGA development
>>> myself, past whiteboarding.
>>>
>>  From Lattice ECP5 sysCONFIG Usage Guide FPGA-TN-02039.
>> 
>> LFE5-45 - 8.86Mb
>> 
>> 
>>  From Xilinx UG470
>> Xilinx Artix 35T and 50T need the same 17.536 Mb
>> 
>> MK
>Why complicate things with memory soooo cheap ??? Just store raw data...

Compression could save bootup time. The Artix7 that I'm using now is
only 17 mbits, but some of the Vertix chips are approaching a gigabit.
Luckily, I can't afford them.

https://www.digikey.com/product-detail/en/xilinx-inc/XCVU37P-3FSVH2892E/122-XCVU37P-3FSVH2892E-ND/10445719

Probably lots of config bits.





-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 161499
Subject: Re: FPGA config sizes
From: dalai lamah <antonio12358@hotmail.com>
Date: Sun, 10 Nov 2019 15:14:16 +0100
Links: << >>  << T >>  << A >>
Un bel giorno John Larkin digiṭ:

> We're planning a new universal boot loader for a family of ST
> processors. The uP would host the loader in a bit of local flash and
> read an outboard serial flash to get the specific application code and
> one or more FPGA configurations.
> 
> So, how many config bits might there be for a modern mid-range FPGA
> doing a moderately complex application? 
> 
> I think we could enable compression too.
> 
> Please consider this a PHB type question. I don't do FPGA development
> myself, past whiteboarding.

My PHB answer would be 32 Mbit.

However, "mid-range" FPGA is a very broad definition. These days I would
call mid-range something like the Spartan 7 family, but probably someone
could argue that it is already low-range. So you could choose 32 Mbit
(which is the maximum bitstream size required for the Spartan-7 and for a
mid-range Artix 7) or go a little further to accomodate also the mid-range
Kintex-7. See table 1-1:

https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf

-- 
Fletto i muscoli e sono nel vuoto.



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