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 161300

Article: 161300
Subject: Re: Hello
From: F6EEQ@wanadoo.fr
Date: Mon, 25 Mar 2019 00:33:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Rick,

Thanks for info.
I already have some DDS knowledge from tests with =C2=B5C and AD9850, but y=
ou gave some interesting hints.
Will consider them, when I'll be a little more advanced in my designing the=
 FPGA DDS.

Cheers and have a nice week.
Gerard.

Article: 161301
Subject: Re: High-level synthesis - MyHDL?
From: Svenn Are Bjerkem <svenn.bjerkem@gmail.com>
Date: Mon, 25 Mar 2019 02:58:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, March 24, 2019 at 11:01:05 PM UTC+1, Jan Coombs wrote:
> On Sun, 24 Mar 2019 08:46:20 -0700 (PDT)
> Svenn Are Bjerkem  wrote:
>=20
> > On Sunday, March 24, 2019 at 8:31:34 AM UTC+1, Jan Coombs wrote:
> > > On Sat, 23 Mar 2019 19:45:06 -0700 (PDT)
> > > Kevin Neilson  wrote:
> > >=20
> > > > "Hardware Construction Language":  that's a good phrase.  I write a=
 lot of Matlab that generates Verilog.  I wish I didn't have to, but that's=
 the way it is.
> > >=20
> > > Could you construct and simulate with MyHDL?  The verilog
> > > would then be just a simple export. [1]
> > >=20
> > > Jan Coombs
> >=20
> > I read on the myhdl discourse that there seems to be a problem with the=
 myhdl owner not maintaining myhdl the way a proper project owner should. C=
are to comment on that?
>=20
> Yes, this is a problem. The BDFL found time to consolidate
> progress to a 0.10 release. The team look capable, but their
> interests will likely diverge/fork if the leadership does not
> improve.=20
>=20
> What else combines the constructional power of the Python
> ecosystem, with simulation speed equal to other free tools
> [1], and spits out Verilog or VHDL?

The reason I don't write assembly these days is that gcc does the job for m=
e *and* that there is a certain safety that gcc will not disappear because =
some leadership wanders off to more interesting projects. This has happened=
 to "fast" tools in the past, and it will happen to "fast" tools in the fut=
ure. When I decide to put a massive effort into learning something, I would=
 like to know where I am heading. The current situation at myhdl is rocking=
 my trust in it.

It is not that I am not willing to look into new ways of resolving my devel=
opment and verification tasks. I am looking into both myhdl and cocotb[2] a=
nd I use ghdl as my simulator. cocotb managed to get their things together =
regarding the massive improvement in ghdl[3] on vhdl-2008, myhdl seem to st=
ill think iverilog is the only way to cosimulate in the FOSS world.

[2] http://potential.ventures/cocotb/
[3] https://github.com/ghdl/ghdl

--=20
Svenn


Article: 161302
Subject: Re: Hello
From: gnuarm.deletethisbit@gmail.com
Date: Mon, 25 Mar 2019 08:10:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, March 25, 2019 at 3:33:11 AM UTC-4, F6...@wanadoo.fr wrote:
> Hi Rick,
>=20
> Thanks for info.
> I already have some DDS knowledge from tests with =C2=B5C and AD9850, but=
 you gave some interesting hints.
> Will consider them, when I'll be a little more advanced in my designing t=
he FPGA DDS.
>=20
> Cheers and have a nice week.
> Gerard.

Please return to report your results or to discuss issues.=20

Rick C.

Article: 161303
Subject: Re: High-level synthesis
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Mon, 25 Mar 2019 10:16:58 -0700
Links: << >>  << T >>  << A >>
On 3/23/19 9:21 PM, A.P.Richelieu wrote:
> Den 2019-03-23 kl. 05:43, skrev A.P.Richelieu:
>> Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
>>> On 3/21/19 9:37 PM, A.P.Richelieu wrote:
>>>> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
>>>>> It's been about 3 years since I've done any *serious* FPGA work. I 
>>>>> used mostly VHDL or sometimes my own Matlab scripts to create 
>>>>> automated VHDL files.
>>>>>
>>>>> I would like to know if anyone has used High-level synthesis 
>>>>> recetnly for *real* work and if so, would they recommend that 
>>>>> people learn it?
>>>>>
>>>>>
>>>>>
>>>>
>>>> We are working on a system where we connect an FPGA and a CPU.
>>>> The FPGA will implement almost 20-30 peripherals.
>>>> The CPU will run Linux, and will need a driver for each type
>>>> of peripheral.
>>>>
>>>> The Linux driver for each peripheral type will contain a main header 
>>>> file, and a file describing the user interface (I.E: the peripheral 
>>>> registers)
>>>>
>>>> A register could look like:
>>>>
>>>> typedef struct uart_mode_s {
>>>>      uint32_t    bits:4;
>>>>      uint32_t    parity:1;
>>>>      uint32_t    odd:1;
>>>>      uint32_t    encoding:2;
>>>>      uint32_t    baud:24;
>>>> } uart_mode_t;
>>>>
>>>> I use the register header file as input to a Python program to 
>>>> generate the register in VHDL. The Python program will generate a 
>>>> package
>>>> containing the register with a std_logic_vector, and functions which
>>>> will convert to and from a "record" so I can use the high level view
>>>> of the register in VHDL.
>>>>
>>>> If I change the C header file in the driver, then the VHDL code will 
>>>> also change, due to dependencies in the build.
>>>>
>>>> Plan to have another Python program which will take a CSV
>>>> file and use the contents to instantiate peripherals, and
>>>> to generate the interface to the processor, including the address
>>>> decoding. (Perhaps a JSON file will be better, though)
>>>>
>>>> This allows me to adopt to changing requirements and save a lot of time
>>>> as well as keeping the driver and the peripheral in sync.
>>>>
>>>> I know others that do it the same way.
>>>>
>>>> AP
>>>
>>> If you haven't gotten too deep into writing your own code yet, you 
>>> may want to check out a project I've been working on sporadically for 
>>> a while now.  https://github.com/NJDFan/register-maps
>>>
>>> There's also a more standard format for describing registers, 
>>> IP-XACT, which like mine is XML-based.  I found it impossibly obtuse 
>>> to work with, but note it for the record.
>>>
>>
>> Thank You,
>> I will have a look.
>> I was discussing this with the guy that has generated the FPGA
>> code for my current project, and he suggested an XML based
>> approach instead of C.
>> If I was going that route, to start from a description and
>> generate both C and VHDL, I would probably use a JSON format,
>> since they are so much easier to read.
>>
>> In my mind the best way is to start off with the C driver.
>> If you like us are running Linux & U-Boot, then you
>> have an API for the driver, which needs to be followed.
>>
>> The H/W implementation of all the peripherals I have seen basically
>> suck, and the C driver implementer has to overcome all the deficiencies
>> forced upon him/her by the chip designers.
>>
>> The proper approach is to start with the API and then
>> figure out how to implement this in a driver in the most efficient way.
>>
>> spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags flags)
>> {
>>     SPI->START = flags;        // Activate CS on request
>>     strncpy(SPI->FIFO, src, size);
>>     SPI->STOP  = flags;        // Deactivate CS on request
>> }
>>
>> Once I have the driver figured out, I already have the headers,
>> so I do not want to create XML to regenerate what I already have.
>>
>> AP
> 
> Had a brief look at your stuff at
> 
> * https://github.com/NJDFan/register-maps
> 
> This is mainly to do address decoding, right?
> Do you have any support for the actual fields inside the registers?
> That is a primary function I would be looking for.
> 
> I can actually see the use of such tool for me,
> if my C struct parser generates the XML (or JSON)
> for an intermediate representation.
> 
> BR
> AP

Yep.  Registers can have fields of types signed, unsigned, or bits. 
That generates VHDL records with named fields of types SIGNED, UNSIGNED, 
and STD_LOGIC_VECTOR (or STD_LOGIC for single bit fields) and functions 
to translate the records to/from a STD_LOGIC_VECTOR the size of the 
read/write bus, as well as procedures to modify a structured register 
from a write data bus that has byte enables.

If you use the high-level API (suitable for "I want to implement these 
registers on flops", not for "I want to implement a large BRAM for 
this.") you wind up with the entire thing in a 
t_<component_name>_regfile, which is a record type where each register 
(or register array) is a field.  So you wind up using things like 
regfile.ctl.enable to interface with your logic.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 161304
Subject: Re: High-level synthesis - MyHDL?
From: David Brown <david.brown@hesbynett.no>
Date: Mon, 25 Mar 2019 21:29:45 +0100
Links: << >>  << T >>  << A >>
On 25/03/2019 10:58, Svenn Are Bjerkem wrote:
> On Sunday, March 24, 2019 at 11:01:05 PM UTC+1, Jan Coombs wrote:
>> On Sun, 24 Mar 2019 08:46:20 -0700 (PDT)
>> Svenn Are Bjerkem  wrote:
>>
>>> On Sunday, March 24, 2019 at 8:31:34 AM UTC+1, Jan Coombs wrote:
>>>> On Sat, 23 Mar 2019 19:45:06 -0700 (PDT)
>>>> Kevin Neilson  wrote:
>>>>
>>>>> "Hardware Construction Language":  that's a good phrase.  I write a lot of Matlab that generates Verilog.  I wish I didn't have to, but that's the way it is.
>>>>
>>>> Could you construct and simulate with MyHDL?  The verilog
>>>> would then be just a simple export. [1]
>>>>
>>>> Jan Coombs
>>>
>>> I read on the myhdl discourse that there seems to be a problem with the myhdl owner not maintaining myhdl the way a proper project owner should. Care to comment on that?
>>
>> Yes, this is a problem. The BDFL found time to consolidate
>> progress to a 0.10 release. The team look capable, but their
>> interests will likely diverge/fork if the leadership does not
>> improve.
>>
>> What else combines the constructional power of the Python
>> ecosystem, with simulation speed equal to other free tools
>> [1], and spits out Verilog or VHDL?
> 
> The reason I don't write assembly these days is that gcc does the job for me *and* that there is a certain safety that gcc will not disappear because some leadership wanders off to more interesting projects. This has happened to "fast" tools in the past, and it will happen to "fast" tools in the future. When I decide to put a massive effort into learning something, I would like to know where I am heading. The current situation at myhdl is rocking my trust in it.
> 
> It is not that I am not willing to look into new ways of resolving my development and verification tasks. I am looking into both myhdl and cocotb[2] and I use ghdl as my simulator. cocotb managed to get their things together regarding the massive improvement in ghdl[3] on vhdl-2008, myhdl seem to still think iverilog is the only way to cosimulate in the FOSS world.
> 
> [2] http://potential.ventures/cocotb/
> [3] https://github.com/ghdl/ghdl
> 

Have you considered Spinal <https://github.com/SpinalHDL> ?  It is a 
high level HDL based on Scala.


Article: 161305
Subject: Re: High-level synthesis
From: gnuarm.deletethisbit@gmail.com
Date: Mon, 25 Mar 2019 15:12:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, March 25, 2019 at 1:17:02 PM UTC-4, Rob Gaddi wrote:
> On 3/23/19 9:21 PM, A.P.Richelieu wrote:
> > Den 2019-03-23 kl. 05:43, skrev A.P.Richelieu:
> >> Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
> >>> On 3/21/19 9:37 PM, A.P.Richelieu wrote:
> >>>> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
> >>>>> It's been about 3 years since I've done any *serious* FPGA work. I=
=20
> >>>>> used mostly VHDL or sometimes my own Matlab scripts to create=20
> >>>>> automated VHDL files.
> >>>>>
> >>>>> I would like to know if anyone has used High-level synthesis=20
> >>>>> recetnly for *real* work and if so, would they recommend that=20
> >>>>> people learn it?
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> We are working on a system where we connect an FPGA and a CPU.
> >>>> The FPGA will implement almost 20-30 peripherals.
> >>>> The CPU will run Linux, and will need a driver for each type
> >>>> of peripheral.
> >>>>
> >>>> The Linux driver for each peripheral type will contain a main header=
=20
> >>>> file, and a file describing the user interface (I.E: the peripheral=
=20
> >>>> registers)
> >>>>
> >>>> A register could look like:
> >>>>
> >>>> typedef struct uart_mode_s {
> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 bits:4;
> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 parity:1;
> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 odd:1;
> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 encoding:2;
> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 baud:24;
> >>>> } uart_mode_t;
> >>>>
> >>>> I use the register header file as input to a Python program to=20
> >>>> generate the register in VHDL. The Python program will generate a=20
> >>>> package
> >>>> containing the register with a std_logic_vector, and functions which
> >>>> will convert to and from a "record" so I can use the high level view
> >>>> of the register in VHDL.
> >>>>
> >>>> If I change the C header file in the driver, then the VHDL code will=
=20
> >>>> also change, due to dependencies in the build.
> >>>>
> >>>> Plan to have another Python program which will take a CSV
> >>>> file and use the contents to instantiate peripherals, and
> >>>> to generate the interface to the processor, including the address
> >>>> decoding. (Perhaps a JSON file will be better, though)
> >>>>
> >>>> This allows me to adopt to changing requirements and save a lot of t=
ime
> >>>> as well as keeping the driver and the peripheral in sync.
> >>>>
> >>>> I know others that do it the same way.
> >>>>
> >>>> AP
> >>>
> >>> If you haven't gotten too deep into writing your own code yet, you=20
> >>> may want to check out a project I've been working on sporadically for=
=20
> >>> a while now.=C2=A0 https://github.com/NJDFan/register-maps
> >>>
> >>> There's also a more standard format for describing registers,=20
> >>> IP-XACT, which like mine is XML-based.=C2=A0 I found it impossibly ob=
tuse=20
> >>> to work with, but note it for the record.
> >>>
> >>
> >> Thank You,
> >> I will have a look.
> >> I was discussing this with the guy that has generated the FPGA
> >> code for my current project, and he suggested an XML based
> >> approach instead of C.
> >> If I was going that route, to start from a description and
> >> generate both C and VHDL, I would probably use a JSON format,
> >> since they are so much easier to read.
> >>
> >> In my mind the best way is to start off with the C driver.
> >> If you like us are running Linux & U-Boot, then you
> >> have an API for the driver, which needs to be followed.
> >>
> >> The H/W implementation of all the peripherals I have seen basically
> >> suck, and the C driver implementer has to overcome all the deficiencie=
s
> >> forced upon him/her by the chip designers.
> >>
> >> The proper approach is to start with the API and then
> >> figure out how to implement this in a driver in the most efficient way=
.
> >>
> >> spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags flag=
s)
> >> {
> >> =C2=A0=C2=A0=C2=A0 SPI->START =3D flags;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 // Activate CS on request
> >> =C2=A0=C2=A0=C2=A0 strncpy(SPI->FIFO, src, size);
> >> =C2=A0=C2=A0=C2=A0 SPI->STOP=C2=A0 =3D flags;=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 // Deactivate CS on request
> >> }
> >>
> >> Once I have the driver figured out, I already have the headers,
> >> so I do not want to create XML to regenerate what I already have.
> >>
> >> AP
> >=20
> > Had a brief look at your stuff at
> >=20
> > * https://github.com/NJDFan/register-maps
> >=20
> > This is mainly to do address decoding, right?
> > Do you have any support for the actual fields inside the registers?
> > That is a primary function I would be looking for.
> >=20
> > I can actually see the use of such tool for me,
> > if my C struct parser generates the XML (or JSON)
> > for an intermediate representation.
> >=20
> > BR
> > AP
>=20
> Yep.  Registers can have fields of types signed, unsigned, or bits.=20
> That generates VHDL records with named fields of types SIGNED, UNSIGNED,=
=20
> and STD_LOGIC_VECTOR (or STD_LOGIC for single bit fields) and functions=
=20
> to translate the records to/from a STD_LOGIC_VECTOR the size of the=20
> read/write bus, as well as procedures to modify a structured register=20
> from a write data bus that has byte enables.
>=20
> If you use the high-level API (suitable for "I want to implement these=20
> registers on flops", not for "I want to implement a large BRAM for=20
> this.") you wind up with the entire thing in a=20
> t_<component_name>_regfile, which is a record type where each register=20
> (or register array) is a field.  So you wind up using things like=20
> regfile.ctl.enable to interface with your logic.

When creating a data structure like this, is there any real reason to use s=
td_logic_vector rather than unsigned?  I tend to use either signed or unsig=
ned for all multibit data types rather than std_logic_vector just because i=
t is easier to type and I've never found an issue. =20

--=20

  Rick C.

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

Article: 161306
Subject: Re: High-level synthesis
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Mon, 25 Mar 2019 15:22:22 -0700
Links: << >>  << T >>  << A >>
On 3/25/19 3:12 PM, gnuarm.deletethisbit@gmail.com wrote:
> On Monday, March 25, 2019 at 1:17:02 PM UTC-4, Rob Gaddi wrote:
>> On 3/23/19 9:21 PM, A.P.Richelieu wrote:
>>> Den 2019-03-23 kl. 05:43, skrev A.P.Richelieu:
>>>> Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
>>>>> On 3/21/19 9:37 PM, A.P.Richelieu wrote:
>>>>>> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
>>>>>>> It's been about 3 years since I've done any *serious* FPGA work. I
>>>>>>> used mostly VHDL or sometimes my own Matlab scripts to create
>>>>>>> automated VHDL files.
>>>>>>>
>>>>>>> I would like to know if anyone has used High-level synthesis
>>>>>>> recetnly for *real* work and if so, would they recommend that
>>>>>>> people learn it?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> We are working on a system where we connect an FPGA and a CPU.
>>>>>> The FPGA will implement almost 20-30 peripherals.
>>>>>> The CPU will run Linux, and will need a driver for each type
>>>>>> of peripheral.
>>>>>>
>>>>>> The Linux driver for each peripheral type will contain a main header
>>>>>> file, and a file describing the user interface (I.E: the peripheral
>>>>>> registers)
>>>>>>
>>>>>> A register could look like:
>>>>>>
>>>>>> typedef struct uart_mode_s {
>>>>>>       uint32_t    bits:4;
>>>>>>       uint32_t    parity:1;
>>>>>>       uint32_t    odd:1;
>>>>>>       uint32_t    encoding:2;
>>>>>>       uint32_t    baud:24;
>>>>>> } uart_mode_t;
>>>>>>
>>>>>> I use the register header file as input to a Python program to
>>>>>> generate the register in VHDL. The Python program will generate a
>>>>>> package
>>>>>> containing the register with a std_logic_vector, and functions which
>>>>>> will convert to and from a "record" so I can use the high level view
>>>>>> of the register in VHDL.
>>>>>>
>>>>>> If I change the C header file in the driver, then the VHDL code will
>>>>>> also change, due to dependencies in the build.
>>>>>>
>>>>>> Plan to have another Python program which will take a CSV
>>>>>> file and use the contents to instantiate peripherals, and
>>>>>> to generate the interface to the processor, including the address
>>>>>> decoding. (Perhaps a JSON file will be better, though)
>>>>>>
>>>>>> This allows me to adopt to changing requirements and save a lot of time
>>>>>> as well as keeping the driver and the peripheral in sync.
>>>>>>
>>>>>> I know others that do it the same way.
>>>>>>
>>>>>> AP
>>>>>
>>>>> If you haven't gotten too deep into writing your own code yet, you
>>>>> may want to check out a project I've been working on sporadically for
>>>>> a while now.  https://github.com/NJDFan/register-maps
>>>>>
>>>>> There's also a more standard format for describing registers,
>>>>> IP-XACT, which like mine is XML-based.  I found it impossibly obtuse
>>>>> to work with, but note it for the record.
>>>>>
>>>>
>>>> Thank You,
>>>> I will have a look.
>>>> I was discussing this with the guy that has generated the FPGA
>>>> code for my current project, and he suggested an XML based
>>>> approach instead of C.
>>>> If I was going that route, to start from a description and
>>>> generate both C and VHDL, I would probably use a JSON format,
>>>> since they are so much easier to read.
>>>>
>>>> In my mind the best way is to start off with the C driver.
>>>> If you like us are running Linux & U-Boot, then you
>>>> have an API for the driver, which needs to be followed.
>>>>
>>>> The H/W implementation of all the peripherals I have seen basically
>>>> suck, and the C driver implementer has to overcome all the deficiencies
>>>> forced upon him/her by the chip designers.
>>>>
>>>> The proper approach is to start with the API and then
>>>> figure out how to implement this in a driver in the most efficient way.
>>>>
>>>> spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags flags)
>>>> {
>>>>      SPI->START = flags;        // Activate CS on request
>>>>      strncpy(SPI->FIFO, src, size);
>>>>      SPI->STOP  = flags;        // Deactivate CS on request
>>>> }
>>>>
>>>> Once I have the driver figured out, I already have the headers,
>>>> so I do not want to create XML to regenerate what I already have.
>>>>
>>>> AP
>>>
>>> Had a brief look at your stuff at
>>>
>>> * https://github.com/NJDFan/register-maps
>>>
>>> This is mainly to do address decoding, right?
>>> Do you have any support for the actual fields inside the registers?
>>> That is a primary function I would be looking for.
>>>
>>> I can actually see the use of such tool for me,
>>> if my C struct parser generates the XML (or JSON)
>>> for an intermediate representation.
>>>
>>> BR
>>> AP
>>
>> Yep.  Registers can have fields of types signed, unsigned, or bits.
>> That generates VHDL records with named fields of types SIGNED, UNSIGNED,
>> and STD_LOGIC_VECTOR (or STD_LOGIC for single bit fields) and functions
>> to translate the records to/from a STD_LOGIC_VECTOR the size of the
>> read/write bus, as well as procedures to modify a structured register
>> from a write data bus that has byte enables.
>>
>> If you use the high-level API (suitable for "I want to implement these
>> registers on flops", not for "I want to implement a large BRAM for
>> this.") you wind up with the entire thing in a
>> t_<component_name>_regfile, which is a record type where each register
>> (or register array) is a field.  So you wind up using things like
>> regfile.ctl.enable to interface with your logic.
> 
> When creating a data structure like this, is there any real reason to use std_logic_vector rather than unsigned?  I tend to use either signed or unsigned for all multibit data types rather than std_logic_vector just because it is easier to type and I've never found an issue.
> 

Just the sake of strong typing.  To my mind, a STD_LOGIC_VECTOR is a 
thing that does not have a numerical interpretation, and as such can't 
have arithmetic applied to it.   An UNSIGNED has one and only one 
numerical interpretation, and as such can't consist of multiple 
bitfields doing different things.  It's easier to verify the code if you 
do it that way, but nothing really essential.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 161307
Subject: Re: High-level synthesis
From: gnuarm.deletethisbit@gmail.com
Date: Mon, 25 Mar 2019 15:25:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, March 25, 2019 at 6:22:25 PM UTC-4, Rob Gaddi wrote:
> On 3/25/19 3:12 PM, gnuarm.deletethisbit@gmail.com wrote:
> > On Monday, March 25, 2019 at 1:17:02 PM UTC-4, Rob Gaddi wrote:
> >> On 3/23/19 9:21 PM, A.P.Richelieu wrote:
> >>> Den 2019-03-23 kl. 05:43, skrev A.P.Richelieu:
> >>>> Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
> >>>>> On 3/21/19 9:37 PM, A.P.Richelieu wrote:
> >>>>>> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
> >>>>>>> It's been about 3 years since I've done any *serious* FPGA work. =
I
> >>>>>>> used mostly VHDL or sometimes my own Matlab scripts to create
> >>>>>>> automated VHDL files.
> >>>>>>>
> >>>>>>> I would like to know if anyone has used High-level synthesis
> >>>>>>> recetnly for *real* work and if so, would they recommend that
> >>>>>>> people learn it?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> We are working on a system where we connect an FPGA and a CPU.
> >>>>>> The FPGA will implement almost 20-30 peripherals.
> >>>>>> The CPU will run Linux, and will need a driver for each type
> >>>>>> of peripheral.
> >>>>>>
> >>>>>> The Linux driver for each peripheral type will contain a main head=
er
> >>>>>> file, and a file describing the user interface (I.E: the periphera=
l
> >>>>>> registers)
> >>>>>>
> >>>>>> A register could look like:
> >>>>>>
> >>>>>> typedef struct uart_mode_s {
> >>>>>>  =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 bits:4;
> >>>>>>  =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 parity:1;
> >>>>>>  =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 odd:1;
> >>>>>>  =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 encoding:2;
> >>>>>>  =C2=A0=C2=A0=C2=A0=C2=A0 uint32_t=C2=A0=C2=A0=C2=A0 baud:24;
> >>>>>> } uart_mode_t;
> >>>>>>
> >>>>>> I use the register header file as input to a Python program to
> >>>>>> generate the register in VHDL. The Python program will generate a
> >>>>>> package
> >>>>>> containing the register with a std_logic_vector, and functions whi=
ch
> >>>>>> will convert to and from a "record" so I can use the high level vi=
ew
> >>>>>> of the register in VHDL.
> >>>>>>
> >>>>>> If I change the C header file in the driver, then the VHDL code wi=
ll
> >>>>>> also change, due to dependencies in the build.
> >>>>>>
> >>>>>> Plan to have another Python program which will take a CSV
> >>>>>> file and use the contents to instantiate peripherals, and
> >>>>>> to generate the interface to the processor, including the address
> >>>>>> decoding. (Perhaps a JSON file will be better, though)
> >>>>>>
> >>>>>> This allows me to adopt to changing requirements and save a lot of=
 time
> >>>>>> as well as keeping the driver and the peripheral in sync.
> >>>>>>
> >>>>>> I know others that do it the same way.
> >>>>>>
> >>>>>> AP
> >>>>>
> >>>>> If you haven't gotten too deep into writing your own code yet, you
> >>>>> may want to check out a project I've been working on sporadically f=
or
> >>>>> a while now.=C2=A0 https://github.com/NJDFan/register-maps
> >>>>>
> >>>>> There's also a more standard format for describing registers,
> >>>>> IP-XACT, which like mine is XML-based.=C2=A0 I found it impossibly =
obtuse
> >>>>> to work with, but note it for the record.
> >>>>>
> >>>>
> >>>> Thank You,
> >>>> I will have a look.
> >>>> I was discussing this with the guy that has generated the FPGA
> >>>> code for my current project, and he suggested an XML based
> >>>> approach instead of C.
> >>>> If I was going that route, to start from a description and
> >>>> generate both C and VHDL, I would probably use a JSON format,
> >>>> since they are so much easier to read.
> >>>>
> >>>> In my mind the best way is to start off with the C driver.
> >>>> If you like us are running Linux & U-Boot, then you
> >>>> have an API for the driver, which needs to be followed.
> >>>>
> >>>> The H/W implementation of all the peripherals I have seen basically
> >>>> suck, and the C driver implementer has to overcome all the deficienc=
ies
> >>>> forced upon him/her by the chip designers.
> >>>>
> >>>> The proper approach is to start with the API and then
> >>>> figure out how to implement this in a driver in the most efficient w=
ay.
> >>>>
> >>>> spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags fl=
ags)
> >>>> {
> >>>>  =C2=A0=C2=A0=C2=A0 SPI->START =3D flags;=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 // Activate CS on request
> >>>>  =C2=A0=C2=A0=C2=A0 strncpy(SPI->FIFO, src, size);
> >>>>  =C2=A0=C2=A0=C2=A0 SPI->STOP=C2=A0 =3D flags;=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 // Deactivate CS on request
> >>>> }
> >>>>
> >>>> Once I have the driver figured out, I already have the headers,
> >>>> so I do not want to create XML to regenerate what I already have.
> >>>>
> >>>> AP
> >>>
> >>> Had a brief look at your stuff at
> >>>
> >>> * https://github.com/NJDFan/register-maps
> >>>
> >>> This is mainly to do address decoding, right?
> >>> Do you have any support for the actual fields inside the registers?
> >>> That is a primary function I would be looking for.
> >>>
> >>> I can actually see the use of such tool for me,
> >>> if my C struct parser generates the XML (or JSON)
> >>> for an intermediate representation.
> >>>
> >>> BR
> >>> AP
> >>
> >> Yep.  Registers can have fields of types signed, unsigned, or bits.
> >> That generates VHDL records with named fields of types SIGNED, UNSIGNE=
D,
> >> and STD_LOGIC_VECTOR (or STD_LOGIC for single bit fields) and function=
s
> >> to translate the records to/from a STD_LOGIC_VECTOR the size of the
> >> read/write bus, as well as procedures to modify a structured register
> >> from a write data bus that has byte enables.
> >>
> >> If you use the high-level API (suitable for "I want to implement these
> >> registers on flops", not for "I want to implement a large BRAM for
> >> this.") you wind up with the entire thing in a
> >> t_<component_name>_regfile, which is a record type where each register
> >> (or register array) is a field.  So you wind up using things like
> >> regfile.ctl.enable to interface with your logic.
> >=20
> > When creating a data structure like this, is there any real reason to u=
se std_logic_vector rather than unsigned?  I tend to use either signed or u=
nsigned for all multibit data types rather than std_logic_vector just becau=
se it is easier to type and I've never found an issue.
> >=20
>=20
> Just the sake of strong typing.  To my mind, a STD_LOGIC_VECTOR is a=20
> thing that does not have a numerical interpretation, and as such can't=20
> have arithmetic applied to it.   An UNSIGNED has one and only one=20
> numerical interpretation, and as such can't consist of multiple=20
> bitfields doing different things.  It's easier to verify the code if you=
=20
> do it that way, but nothing really essential.

There is no such restriction on signed or unsigned.  How does verifying the=
 code change?=20

Rick C.

Article: 161308
Subject: TCS34725 Basys3 VHDL
From: utkudenizal@gmail.com
Date: Tue, 26 Mar 2019 07:39:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi I am trying to use TCS34725 to identify Green and Red Colors, it has I2C interface and i could not find any I2C interface about this and i am not capable to write a protocol code what should I do I am stucked.

I just need when it sees green it turns one led and when it sees red it turns another led.

Article: 161309
Subject: Re: TCS34725 Basys3 VHDL
From: Andy Bennet <andyb@andy.com>
Date: Tue, 26 Mar 2019 17:41:16 +0000
Links: << >>  << T >>  << A >>
On 26/03/2019 14:39, utkudenizal@gmail.com wrote:
> Hi I am trying to use TCS34725 to identify Green and Red Colors, it has I2C interface and i could not find any I2C interface about this and i am not capable to write a protocol code what should I do I am stucked.
> 
> I just need when it sees green it turns one led and when it sees red it turns another led.
> 

Refer to these threads:
https://www.reddit.com/user/kmesne


Article: 161310
Subject: Re: High-level synthesis
From: Anssi Saari <as@sci.fi>
Date: Wed, 27 Mar 2019 10:02:57 +0200
Links: << >>  << T >>  << A >>
Benjamin Couillard <benjamin.couillard@gmail.com> writes:

> I did the same in VHDL about 10 years ago. It worked well for a
> medium-sized system. It was based on a code snippet posted by Jonathan
> Bromley on comp.lang.vhdl

Interesting. Do you still happen to have that VHDL snippet?

Personally, my projects have usually had so few registers I haven't
bothered with any generator. At least in my opinion if you have, say,
less than 20 registers, then who cares. 

However, now I have a project which has quite a lot of registers. I
searched and found a Python script called hdlregs on Github. It's
actually by the guy (Guy Eschemann) who does AirHDL now which is a
payola web service to generate register files with an AXI4 slave
interface.

Hdlregs takes json as input and generates docs in HTML, VHDL code and C
headers. Bus interface is simple address/data/control, user interface to
regs is a single record in and another one out. The script seems to have
some limitations so hardly perfect but good enough for my needs. Then
again, it's in Python so easy to improve. Documentation is zero apart
from one example.

Article: 161311
Subject: Re: High-level synthesis
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Wed, 27 Mar 2019 05:23:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
Le mercredi 27 mars 2019 04:03:00 UTC-4, Anssi Saari a =C3=A9crit=C2=A0:
> Benjamin Couillard <benjamin.couillard@gmail.com> writes:
>=20
> > I did the same in VHDL about 10 years ago. It worked well for a
> > medium-sized system. It was based on a code snippet posted by Jonathan
> > Bromley on comp.lang.vhdl
>=20
> Interesting. Do you still happen to have that VHDL snippet?
>=20

https://groups.google.com/d/msg/comp.lang.vhdl/0JrSaPFUJ1k/JzDlR9MZVMUJ

Make sure to read the whole thread as there is a small typo in the posted c=
ode. The typo is corrected in a later post.



Article: 161312
Subject: Re: High-level synthesis
From: Espen Tallaksen <espen.tallaksen@bitvis.no>
Date: Wed, 27 Mar 2019 08:31:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Feel free to use RegisterWizard from Bitvis.  This is freeware - so no cost=
. https://bitvis.no/dev-tools/register-wizard/

The input is in JSON, and is easy to use by anyone.
It is well documented - including examples.
The generated bus interface is what we call Simple Bus Interface (SBI), whi=
ch is what people some year ago would have called a simple SRAM interface.
If you need a more advanced interface you can just make a general wrapper.

If you download the open source UVVM (Universal VHDL Verification Methodolo=
gy) from Github (https://github.com/UVVM/UVVM) you will get a BFM (Bus func=
tional model) and VVC (verification component) with procedures to access th=
e SBI interface (or Avalon or AXI4-lite) in a testbench.

- Espen

Article: 161313
Subject: Replaceme EPROM by CPLD/FPGA
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 28 Mar 2019 13:28:46 +0100
Links: << >>  << T >>  << A >>
We have a product that includes a small parallel OTP memory. These devices
get very hard to get and no easy alternative is available that fits in the
very small available space. A PLCC32 EPROM will not fit unfortunately.
Since the memory array is small (256x4 bits), I was thinking this could
easily fit into a CPLD or FPGA. But how to program this?

The memory is used for calibration data. So in production, the device is
characterized, data block is calculated and programmed.

Usually you use the vendor tools to generate a bitstream from an HDL
design. But are there options to generate these bitstreams during the
production cycle, in only a few seconds? Something like HDL + DATA =
BITSTREAM. And then burn the resulting bitsream in the device.

A device like the Lattice ispMACH 4000 seems a possible candidate.


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

It's better to burn out than it is to rust.

Article: 161314
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 28 Mar 2019 06:32:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, Stef wrote:
> We have a product that includes a small parallel OTP memory. These device=
s
> get very hard to get and no easy alternative is available that fits in th=
e
> very small available space. A PLCC32 EPROM will not fit unfortunately.
> Since the memory array is small (256x4 bits), I was thinking this could
> easily fit into a CPLD or FPGA. But how to program this?
>=20
> The memory is used for calibration data. So in production, the device is
> characterized, data block is calculated and programmed.
>=20
> Usually you use the vendor tools to generate a bitstream from an HDL
> design. But are there options to generate these bitstreams during the
> production cycle, in only a few seconds? Something like HDL + DATA =3D
> BITSTREAM. And then burn the resulting bitsream in the device.
>=20
> A device like the Lattice ispMACH 4000 seems a possible candidate.

You could program it as a constant array.  Then let the logic generate as a=
ppropriate.  In a device like the ispMACH 4000 which has no memory, this mi=
ght not fit well and would require the full tool set to be used.=20

If you pick a device that has internal memory, you can use a part that can =
be placed and routed once and the contents of the memory loaded in one of t=
he final steps using a lot less of the tools. =20

That said, I have not done this myself.  I have only seen it described by o=
thers.  For a data point, our production testing programs an FPGA and it ta=
kes around 20 seconds for the smallish device we use.  Any compilation port=
ion would change that to minutes, but maybe not too many for such a simple =
HDL file.  I don't know how long it would take to load the memory.  That mi=
ght even be doable as a separate step after the programming.=20

The most affordable devices I am familiar with are the iCE40 line.  There a=
re a number of flavors so you could shop around to find the cheapest.  Like=
 many FPGAs they come in an array of packages which may or may not suit you=
r design.  A chip scale package with 0.25 spaced balls might not suit your =
assembly process. =20

Another alternative, if the memory speed can be slow, would be to use a ser=
ial PROM device as your in circuit programmable memory and use an ispMACH 4=
000 to turn it into a parallel device.  If your calibration data is read se=
quentially this becomes very simple indeed and can be pretty fast once star=
ted.=20

Just kicking around some ideas.=20

--=20

  Rick C.

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

Article: 161315
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Theo <theom+news@chiark.greenend.org.uk>
Date: 28 Mar 2019 13:47:57 +0000 (GMT)
Links: << >>  << T >>  << A >>
Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote:
> Usually you use the vendor tools to generate a bitstream from an HDL
> design. But are there options to generate these bitstreams during the
> production cycle, in only a few seconds? Something like HDL + DATA =
> BITSTREAM. And then burn the resulting bitsream in the device.

Intel Quartus has an 'Update Memory Initialization File' step where you can
change the memory contents of an existing project without recompiling.  I
don't know how much project scaffolding you'd need (you still need to run
the Assembler step to generate bitfiles afterwards, so I don't think you can
edit an existing bitfile).  It's not super quick (maybe ten seconds for a
Cyclone V) but better than a recompile.

I think some of the Lattice parts have a user flash memory but I haven't
used those:
http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086

I suppose another option is a small SPI/I2C flash chip and a CPLD that reads
the contents in at powerup time.  Or a NOR flash that you can program
externally (but programming header with 8 address, 4 data, 3 control wires -
might be too big) or another chip to drive them (I2C I/O expander for
instance and a 3/4 pin header)

> A device like the Lattice ispMACH 4000 seems a possible candidate.

Does your old design have voltage requirements like 5V capability?

Theo

Article: 161316
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 28 Mar 2019 15:14:44 +0100
Links: << >>  << T >>  << A >>
On 2019-03-28 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:
> On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, Stef wrote:
>> We have a product that includes a small parallel OTP memory. These devices
>> get very hard to get and no easy alternative is available that fits in the
>> very small available space. A PLCC32 EPROM will not fit unfortunately.
>> Since the memory array is small (256x4 bits), I was thinking this could
>> easily fit into a CPLD or FPGA. But how to program this?
>> 
>> The memory is used for calibration data. So in production, the device is
>> characterized, data block is calculated and programmed.
>> 
>> Usually you use the vendor tools to generate a bitstream from an HDL
>> design. But are there options to generate these bitstreams during the
>> production cycle, in only a few seconds? Something like HDL + DATA =
>> BITSTREAM. And then burn the resulting bitsream in the device.
>> 
>> A device like the Lattice ispMACH 4000 seems a possible candidate.
>
> You could program it as a constant array.  Then let the logic generate as appropriate.  In a device like the ispMACH 4000 which has no memory, this might not fit well and would require the full tool set to be used. 
>
> If you pick a device that has internal memory, you can use a part that can be placed and routed once and the contents of the memory loaded in one of the final steps using a lot less of the tools.  
>
> That said, I have not done this myself.  I have only seen it described by others.  For a data point, our production testing programs an FPGA and it takes around 20 seconds for the smallish device we use.  Any compilation portion would change that to minutes, but maybe not too many for such a simple HDL file.  I don't know how long it would take to load the memory.  That might even be doable as a separate step after the programming. 
>
> The most affordable devices I am familiar with are the iCE40 line.  There are a number of flavors so you could shop around to find the cheapest.  Like many FPGAs they come in an array of packages which may or may not suit your design.  A chip scale package with 0.25 spaced balls might not suit your assembly process.  
>
> Another alternative, if the memory speed can be slow, would be to use a serial PROM device as your in circuit programmable memory and use an ispMACH 4000 to turn it into a parallel device.  If your calibration data is read sequentially this becomes very simple indeed and can be pretty fast once started. 
>
> Just kicking around some ideas. 

Thanks for the input.
Data is read sequentially, so approaches like that are doable. Access is
rather slow, so if we go that route, MCU solutions (with internal EEPROM)
may be possible too. 


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

It's better to burn out than it is to rust.

Article: 161317
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 28 Mar 2019 15:24:44 +0100
Links: << >>  << T >>  << A >>
On 2019-03-28 Theo wrote in comp.arch.fpga:
> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote:
>> Usually you use the vendor tools to generate a bitstream from an HDL
>> design. But are there options to generate these bitstreams during the
>> production cycle, in only a few seconds? Something like HDL + DATA =
>> BITSTREAM. And then burn the resulting bitsream in the device.
>
> Intel Quartus has an 'Update Memory Initialization File' step where you can
> change the memory contents of an existing project without recompiling.  I
> don't know how much project scaffolding you'd need (you still need to run
> the Assembler step to generate bitfiles afterwards, so I don't think you can
> edit an existing bitfile).  It's not super quick (maybe ten seconds for a
> Cyclone V) but better than a recompile.
>
> I think some of the Lattice parts have a user flash memory but I haven't
> used those:
> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086
>
> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads
> the contents in at powerup time.  Or a NOR flash that you can program
> externally (but programming header with 8 address, 4 data, 3 control wires -
> might be too big) or another chip to drive them (I2C I/O expander for
> instance and a 3/4 pin header)
>
>> A device like the Lattice ispMACH 4000 seems a possible candidate.
>
> Does your old design have voltage requirements like 5V capability?

The supply is 5V, but the interface on the reading device is 3V3 with 5V
tolerant IO. So adding 3V3 regulation for the memory power should work.

Another limitation is that that the preferred programming interface is
through the available connections: Address (8), data (4), control (1 + 
1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could
be used as well.

This is a reason why parallel EEPROM (FLASH) is not an option. Those
devices all require access to all address and data to enter the programming
sequence. (or do you know a flash that does not require this?)
Or use a CPLD to generate those sequences? (based on the states of the free
pins?)

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

It's better to burn out than it is to rust.

Article: 161318
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 28 Mar 2019 07:50:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, March 28, 2019 at 10:28:54 AM UTC-4, Stef wrote:
> On 2019-03-28 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:
> > On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, Stef wrote:
> >> We have a product that includes a small parallel OTP memory. These dev=
ices
> >> get very hard to get and no easy alternative is available that fits in=
 the
> >> very small available space. A PLCC32 EPROM will not fit unfortunately.
> >> Since the memory array is small (256x4 bits), I was thinking this coul=
d
> >> easily fit into a CPLD or FPGA. But how to program this?
> >>=20
> >> The memory is used for calibration data. So in production, the device =
is
> >> characterized, data block is calculated and programmed.
> >>=20
> >> Usually you use the vendor tools to generate a bitstream from an HDL
> >> design. But are there options to generate these bitstreams during the
> >> production cycle, in only a few seconds? Something like HDL + DATA =3D
> >> BITSTREAM. And then burn the resulting bitsream in the device.
> >>=20
> >> A device like the Lattice ispMACH 4000 seems a possible candidate.
> >
> > You could program it as a constant array.  Then let the logic generate =
as appropriate.  In a device like the ispMACH 4000 which has no memory, thi=
s might not fit well and would require the full tool set to be used.=20
> >
> > If you pick a device that has internal memory, you can use a part that =
can be placed and routed once and the contents of the memory loaded in one =
of the final steps using a lot less of the tools. =20
> >
> > That said, I have not done this myself.  I have only seen it described =
by others.  For a data point, our production testing programs an FPGA and i=
t takes around 20 seconds for the smallish device we use.  Any compilation =
portion would change that to minutes, but maybe not too many for such a sim=
ple HDL file.  I don't know how long it would take to load the memory.  Tha=
t might even be doable as a separate step after the programming.=20
> >
> > The most affordable devices I am familiar with are the iCE40 line.  The=
re are a number of flavors so you could shop around to find the cheapest.  =
Like many FPGAs they come in an array of packages which may or may not suit=
 your design.  A chip scale package with 0.25 spaced balls might not suit y=
our assembly process. =20
> >
> > Another alternative, if the memory speed can be slow, would be to use a=
 serial PROM device as your in circuit programmable memory and use an ispMA=
CH 4000 to turn it into a parallel device.  If your calibration data is rea=
d sequentially this becomes very simple indeed and can be pretty fast once =
started.=20
> >
> > Just kicking around some ideas.=20
>=20
> Thanks for the input.
> Data is read sequentially, so approaches like that are doable. Access is
> rather slow, so if we go that route, MCU solutions (with internal EEPROM)
> may be possible too.=20

I had forgotten that the Lattice XO2 and XO3 devices have User Flash Memory=
 (UFM) for just this sort of application (configuration data).  The XO2-640=
 part (smallest with UFM) in a 48 pin QFN is just $3.12 qty 100.  The XO3 c=
an be even lower cost, but only available in BGA style packaging.  I found =
a couple of app notes on using it, one specifically for making it into a pa=
rallel interface RAM.=20

Reference Design RD1126

--=20

  Rick C.

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

Article: 161319
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Anssi Saari <as@sci.fi>
Date: Thu, 28 Mar 2019 17:00:13 +0200
Links: << >>  << T >>  << A >>
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> writes:

> Usually you use the vendor tools to generate a bitstream from an HDL
> design. But are there options to generate these bitstreams during the
> production cycle, in only a few seconds? Something like HDL + DATA =
> BITSTREAM. And then burn the resulting bitsream in the device.

The HDL for this would be pretty short, maybe just an array declaration
with the calibration data and then a single assignment to the output
from the array based on the address input. So very easy to generate with
a little software.

Most vendor tools have automation possibilities so the tool flow can be
done with a single command. Might take longer than a few seconds though.
On the other hand, if there's a limited number of bitstreams then it
could be possible to generate and store all of them beforehand.

Another way could be to use the user flash memory which is included in
Intel's MaxII and MaxV CPLDs. The size is 8192 bits so big enough. You'd
program the CPLD with the same design and only the UFM part of the flash
would need to be programmed in production.

Article: 161320
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Tim <tim@bugblat.invalid>
Date: Thu, 28 Mar 2019 15:32:11 +0000
Links: << >>  << T >>  << A >>
On 28/03/2019 12:28, Stef wrote:
> We have a product that includes a small parallel OTP memory. These devices
> get very hard to get and no easy alternative is available that fits in the
> very small available space. A PLCC32 EPROM will not fit unfortunately.
> Since the memory array is small (256x4 bits), I was thinking this could
> easily fit into a CPLD or FPGA. But how to program this?
> 
> The memory is used for calibration data. So in production, the device is
> characterized, data block is calculated and programmed.
> 
> Usually you use the vendor tools to generate a bitstream from an HDL
> design. But are there options to generate these bitstreams during the
> production cycle, in only a few seconds? Something like HDL + DATA =
> BITSTREAM. And then burn the resulting bitsream in the device.
> 
> A device like the Lattice ispMACH 4000 seems a possible candidate.
> 

CAT34C02? 2Kb I2C EEPROM, small, cheap, commodity, can be locked by 
software, OK at 3.3V and 5V. Not as amusing as a CPLD.


Article: 161321
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 28 Mar 2019 18:00:40 +0100
Links: << >>  << T >>  << A >>
On 2019-03-28 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:
> On Thursday, March 28, 2019 at 10:28:54 AM UTC-4, Stef wrote:
>> On 2019-03-28 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:
>> > On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, Stef wrote:
>> >> We have a product that includes a small parallel OTP memory. These devices
>> >> get very hard to get and no easy alternative is available that fits in the
>> >> very small available space. A PLCC32 EPROM will not fit unfortunately.
>> >> Since the memory array is small (256x4 bits), I was thinking this could
>> >> easily fit into a CPLD or FPGA. But how to program this?
>> >> 
>> >> The memory is used for calibration data. So in production, the device is
>> >> characterized, data block is calculated and programmed.
>> >> 
>> >> Usually you use the vendor tools to generate a bitstream from an HDL
>> >> design. But are there options to generate these bitstreams during the
>> >> production cycle, in only a few seconds? Something like HDL + DATA =
>> >> BITSTREAM. And then burn the resulting bitsream in the device.
>> >> 
>> >> A device like the Lattice ispMACH 4000 seems a possible candidate.
>> >
>> > You could program it as a constant array.  Then let the logic generate as appropriate.  In a device like the ispMACH 4000 which has no memory, this might not fit well and would require the full tool set to be used. 
>> >
>> > If you pick a device that has internal memory, you can use a part that can be placed and routed once and the contents of the memory loaded in one of the final steps using a lot less of the tools.  
>> >
>> > That said, I have not done this myself.  I have only seen it described by others.  For a data point, our production testing programs an FPGA and it takes around 20 seconds for the smallish device we use.  Any compilation portion would change that to minutes, but maybe not too many for such a simple HDL file.  I don't know how long it would take to load the memory.  That might even be doable as a separate step after the programming. 
>> >
>> > The most affordable devices I am familiar with are the iCE40 line.  There are a number of flavors so you could shop around to find the cheapest.  Like many FPGAs they come in an array of packages which may or may not suit your design.  A chip scale package with 0.25 spaced balls might not suit your assembly process.  
>> >
>> > Another alternative, if the memory speed can be slow, would be to use a serial PROM device as your in circuit programmable memory and use an ispMACH 4000 to turn it into a parallel device.  If your calibration data is read sequentially this becomes very simple indeed and can be pretty fast once started. 
>> >
>> > Just kicking around some ideas. 
>> 
>> Thanks for the input.
>> Data is read sequentially, so approaches like that are doable. Access is
>> rather slow, so if we go that route, MCU solutions (with internal EEPROM)
>> may be possible too. 
>
> I had forgotten that the Lattice XO2 and XO3 devices have User Flash Memory (UFM) for just this sort of application (configuration data).  The XO2-640 part (smallest with UFM) in a 48 pin QFN is just $3.12 qty 100.  The XO3 can be even lower cost, but only available in BGA style packaging.  I found a couple of app notes on using it, one specifically for making it into a parallel interface RAM. 
>
> Reference Design RD1126

Nice reference, thanks.

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

It takes less time to do a thing right than it does to explain why you
did it wrong.
		-- H.W. Longfellow

Article: 161322
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 28 Mar 2019 18:04:32 +0100
Links: << >>  << T >>  << A >>
On 2019-03-28 Anssi Saari wrote in comp.arch.fpga:
> Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> writes:
>
>> Usually you use the vendor tools to generate a bitstream from an HDL
>> design. But are there options to generate these bitstreams during the
>> production cycle, in only a few seconds? Something like HDL + DATA =
>> BITSTREAM. And then burn the resulting bitsream in the device.
>
> The HDL for this would be pretty short, maybe just an array declaration
> with the calibration data and then a single assignment to the output
> from the array based on the address input. So very easy to generate with
> a little software.
>
> Most vendor tools have automation possibilities so the tool flow can be
> done with a single command. Might take longer than a few seconds though.
> On the other hand, if there's a limited number of bitstreams then it
> could be possible to generate and store all of them beforehand.

In theory there are 1024 bits, but not all will be used/changed. But
even then, the number of posibilities is rather high. A few seconds is
a wide range, but not into the minutes. ;-) We will see...


> Another way could be to use the user flash memory which is included in
> Intel's MaxII and MaxV CPLDs. The size is 8192 bits so big enough. You'd
> program the CPLD with the same design and only the UFM part of the flash
> would need to be programmed in production.

Ah, similar to Ricks' approach, but then with intel. Thanks.

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

A lot of people I know believe in positive thinking, and so do I.  
I believe everything positively stinks.
-- Lew Col

Article: 161323
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 28 Mar 2019 18:06:32 +0100
Links: << >>  << T >>  << A >>
On 2019-03-28 Tim wrote in comp.arch.fpga:
> On 28/03/2019 12:28, Stef wrote:
>> We have a product that includes a small parallel OTP memory. These devices
>> get very hard to get and no easy alternative is available that fits in the
>> very small available space. A PLCC32 EPROM will not fit unfortunately.
>> Since the memory array is small (256x4 bits), I was thinking this could
>> easily fit into a CPLD or FPGA. But how to program this?
>> 
>> The memory is used for calibration data. So in production, the device is
>> characterized, data block is calculated and programmed.
>> 
>> Usually you use the vendor tools to generate a bitstream from an HDL
>> design. But are there options to generate these bitstreams during the
>> production cycle, in only a few seconds? Something like HDL + DATA =
>> BITSTREAM. And then burn the resulting bitsream in the device.
>> 
>> A device like the Lattice ispMACH 4000 seems a possible candidate.
>> 
>
> CAT34C02? 2Kb I2C EEPROM, small, cheap, commodity, can be locked by 
> software, OK at 3.3V and 5V. Not as amusing as a CPLD.

This is a serial interface EEPROM, plenty of those around. The required
parallel interface is harder to find unfortunately.

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

Murphy was an optimist.

Article: 161324
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: "A.P.Richelieu" <aprichelieu@gmail.com>
Date: Thu, 28 Mar 2019 21:49:16 +0100
Links: << >>  << T >>  << A >>
Den 2019-03-28 kl. 15:24, skrev Stef:
> On 2019-03-28 Theo wrote in comp.arch.fpga:
>> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote:
>>> Usually you use the vendor tools to generate a bitstream from an HDL
>>> design. But are there options to generate these bitstreams during the
>>> production cycle, in only a few seconds? Something like HDL + DATA =
>>> BITSTREAM. And then burn the resulting bitsream in the device.
>>
>> Intel Quartus has an 'Update Memory Initialization File' step where you can
>> change the memory contents of an existing project without recompiling.  I
>> don't know how much project scaffolding you'd need (you still need to run
>> the Assembler step to generate bitfiles afterwards, so I don't think you can
>> edit an existing bitfile).  It's not super quick (maybe ten seconds for a
>> Cyclone V) but better than a recompile.
>>
>> I think some of the Lattice parts have a user flash memory but I haven't
>> used those:
>> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086
>>
>> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads
>> the contents in at powerup time.  Or a NOR flash that you can program
>> externally (but programming header with 8 address, 4 data, 3 control wires -
>> might be too big) or another chip to drive them (I2C I/O expander for
>> instance and a 3/4 pin header)
>>
>>> A device like the Lattice ispMACH 4000 seems a possible candidate.
>>
>> Does your old design have voltage requirements like 5V capability?
> 
> The supply is 5V, but the interface on the reading device is 3V3 with 5V
> tolerant IO. So adding 3V3 regulation for the memory power should work.
> 
> Another limitation is that that the preferred programming interface is
> through the available connections: Address (8), data (4), control (1 +
> 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could
> be used as well.
> 
> This is a reason why parallel EEPROM (FLASH) is not an option. Those
> devices all require access to all address and data to enter the programming
> sequence. (or do you know a flash that does not require this?)
> Or use a CPLD to generate those sequences? (based on the states of the free
> pins?)
> 
What is reading from the EPROM?
What is the bus speed of the access?

I would not be surprised, if you could not implement this with a 
microcontroller running at a decent clock frequency.

A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package
should be small

The program will look like this:
while (1) {
    port = memory[pins & 0xff];
    oe = (pins & 0x100) ? ON : OFF;
}

AP



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