Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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 SvennArticle: 161302
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
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: 161304On 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
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
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
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: 161308Hi 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
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/kmesneArticle: 161310
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
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
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. - EspenArticle: 161313
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
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/richard11209Article: 161315
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? TheoArticle: 161316
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
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
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/richard11209Article: 161319
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
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
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. LongfellowArticle: 161322
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 ColArticle: 161323
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
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:
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