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
On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
> 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 =
=3D
> >>> BITSTREAM. And then burn the resulting bitsream in the device.
> >>
> >> Intel Quartus has an 'Update Memory Initialization File' step where yo=
u 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 y=
ou can
> >> edit an existing bitfile). It's not super quick (maybe ten seconds fo=
r 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/ApplicationNo=
tes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx=
?document_id=3D39086
> >>
> >> 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 w=
ires -
> >> 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?
> >=20
> > The supply is 5V, but the interface on the reading device is 3V3 with 5=
V
> > tolerant IO. So adding 3V3 regulation for the memory power should work.
> >=20
> > 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 c=
ould
> > be used as well.
> >=20
> > 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 program=
ming
> > 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?)
> >=20
> What is reading from the EPROM?
> What is the bus speed of the access?
>=20
> I would not be surprised, if you could not implement this with a=20
> microcontroller running at a decent clock frequency.
>=20
> A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package
> should be small
>=20
> The program will look like this:
> while (1) {
> port =3D memory[pins & 0xff];
> oe =3D (pins & 0x100) ? ON : OFF;
> }
>=20
> AP
I find it interesting that people often feel MCUs are simpler than programm=
able logic. What your program in particular lacks is the important part, a=
llowing the contents of "memory[]" to be set at manufacturing time. I don'=
t see the use of an MCU to be at all simple. In addition to the above, the=
re is setup code that either needs to be written from scratch by reading th=
e MCU data sheet (starting clocks, initialize I/O banks, brown out detector=
s, etc., etc...) or by starting with the standard startup code and paring o=
ut what is not needed or appropriate. =20
To me, this is inordinately complex compared to the relatively trivial exer=
cise of creating an HDL ROM which is about as complex as the code above and=
setting the details of the chosen I/O pins to be used. The only remaining=
issue is to use the vendor tool to initialize this ROM in the compiled cod=
e or even in the same way it is done now which I think is done by the board=
itself. =20
Not only is the PLD method simpler, it provides a lot more flexibility. =20
--=20
Rick C.
-- Get a 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
Article: 161326
torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com:
> On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
> > 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 HD=
L
> > >>> design. But are there options to generate these bitstreams during t=
he
> > >>> production cycle, in only a few seconds? Something like HDL + DATA =
=3D
> > >>> 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 recompilin=
g. I
> > >> don't know how much project scaffolding you'd need (you still need t=
o 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 hav=
en't
> > >> used those:
> > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/Application=
Notes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.as=
hx?document_id=3D39086
> > >>
> > >> I suppose another option is a small SPI/I2C flash chip and a CPLD th=
at reads
> > >> the contents in at powerup time. Or a NOR flash that you can progra=
m
> > >> 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 fo=
r
> > >> 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?
> > >=20
> > > 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 wor=
k.
> > >=20
> > > Another limitation is that that the preferred programming interface i=
s
> > > 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.
> > >=20
> > > 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 progr=
amming
> > > 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 th=
e free
> > > pins?)
> > >=20
> > What is reading from the EPROM?
> > What is the bus speed of the access?
> >=20
> > I would not be surprised, if you could not implement this with a=20
> > microcontroller running at a decent clock frequency.
> >=20
> > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package
> > should be small
> >=20
> > The program will look like this:
> > while (1) {
> > port =3D memory[pins & 0xff];
> > oe =3D (pins & 0x100) ? ON : OFF;
> > }
> >=20
> > AP
>=20
> I find it interesting that people often feel MCUs are simpler than progra=
mmable logic. What your program in particular lacks is the important part,=
allowing the contents of "memory[]" to be set at manufacturing time. I do=
n't see the use of an MCU to be at all simple. In addition to the above, t=
here is setup code that either needs to be written from scratch by reading =
the MCU data sheet (starting clocks, initialize I/O banks, brown out detect=
ors, etc., etc...) or by starting with the standard startup code and paring=
out what is not needed or appropriate. =20
>=20
> To me, this is inordinately complex compared to the relatively trivial ex=
ercise of creating an HDL ROM which is about as complex as the code above a=
nd setting the details of the chosen I/O pins to be used. The only remaini=
ng issue is to use the vendor tool to initialize this ROM in the compiled c=
ode or even in the same way it is done now which I think is done by the boa=
rd itself. =20
>=20
> Not only is the PLD method simpler, it provides a lot more flexibility. =
=20
if the only thing in your toolbox it hammers, nailing things together alway=
s=20
seem like the obvious choice
at slow speed an mcu could be just as viable, and customizing the array cou=
ld=20
be as simple as patching the bin or hex file programmed into the part
Article: 161327
On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com =
wrote:
> torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.co=
m:
> > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
> > > 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 + DAT=
A =3D
> > > >>> BITSTREAM. And then burn the resulting bitsream in the device.
> > > >>
> > > >> Intel Quartus has an 'Update Memory Initialization File' step wher=
e you can
> > > >> change the memory contents of an existing project without recompil=
ing. 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 thi=
nk you can
> > > >> edit an existing bitfile). It's not super quick (maybe ten second=
s for a
> > > >> Cyclone V) but better than a recompile.
> > > >>
> > > >> I think some of the Lattice parts have a user flash memory but I h=
aven't
> > > >> used those:
> > > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/Applicati=
onNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.=
ashx?document_id=3D39086
> > > >>
> > > >> 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 prog=
ram
> > > >> externally (but programming header with 8 address, 4 data, 3 contr=
ol 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?
> > > >=20
> > > > The supply is 5V, but the interface on the reading device is 3V3 wi=
th 5V
> > > > tolerant IO. So adding 3V3 regulation for the memory power should w=
ork.
> > > >=20
> > > > 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 th=
at could
> > > > be used as well.
> > > >=20
> > > > This is a reason why parallel EEPROM (FLASH) is not an option. Thos=
e
> > > > devices all require access to all address and data to enter the pro=
gramming
> > > > 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?)
> > > >=20
> > > What is reading from the EPROM?
> > > What is the bus speed of the access?
> > >=20
> > > I would not be surprised, if you could not implement this with a=20
> > > microcontroller running at a decent clock frequency.
> > >=20
> > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package
> > > should be small
> > >=20
> > > The program will look like this:
> > > while (1) {
> > > port =3D memory[pins & 0xff];
> > > oe =3D (pins & 0x100) ? ON : OFF;
> > > }
> > >=20
> > > AP
> >=20
> > I find it interesting that people often feel MCUs are simpler than prog=
rammable logic. What your program in particular lacks is the important par=
t, allowing the contents of "memory[]" to be set at manufacturing time. I =
don't see the use of an MCU to be at all simple. In addition to the above,=
there is setup code that either needs to be written from scratch by readin=
g the MCU data sheet (starting clocks, initialize I/O banks, brown out dete=
ctors, etc., etc...) or by starting with the standard startup code and pari=
ng out what is not needed or appropriate. =20
> >=20
> > To me, this is inordinately complex compared to the relatively trivial =
exercise of creating an HDL ROM which is about as complex as the code above=
and setting the details of the chosen I/O pins to be used. The only remai=
ning issue is to use the vendor tool to initialize this ROM in the compiled=
code or even in the same way it is done now which I think is done by the b=
oard itself. =20
> >=20
> > Not only is the PLD method simpler, it provides a lot more flexibility.=
=20
>=20
> if the only thing in your toolbox it hammers, nailing things together alw=
ays=20
> seem like the obvious choice
>=20
> at slow speed an mcu could be just as viable, and customizing the array c=
ould=20
> be as simple as patching the bin or hex file programmed into the part
But you didn't address the additional setup required to write the code for =
the MCU. The ones I've used have a *lot* of features that need to be set u=
p for the MCU to even run. MCU code is always a lot more complex to design=
with than HDL in my experience. =20
"Patching" a hex file is not the way I want to manage configuration data. =
The PLD tools have already dealt with this issue.=20
--=20
Rick C.
-+ Get a 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
Article: 161328
fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com:
> On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.co=
m wrote:
> > torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.=
com:
> > > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
> > > > 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 a=
n HDL
> > > > >>> design. But are there options to generate these bitstreams duri=
ng the
> > > > >>> production cycle, in only a few seconds? Something like HDL + D=
ATA =3D
> > > > >>> BITSTREAM. And then burn the resulting bitsream in the device.
> > > > >>
> > > > >> Intel Quartus has an 'Update Memory Initialization File' step wh=
ere you can
> > > > >> change the memory contents of an existing project without recomp=
iling. I
> > > > >> don't know how much project scaffolding you'd need (you still ne=
ed to run
> > > > >> the Assembler step to generate bitfiles afterwards, so I don't t=
hink you can
> > > > >> edit an existing bitfile). It's not super quick (maybe ten seco=
nds 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/Applica=
tionNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Device=
s.ashx?document_id=3D39086
> > > > >>
> > > > >> I suppose another option is a small SPI/I2C flash chip and a CPL=
D that reads
> > > > >> the contents in at powerup time. Or a NOR flash that you can pr=
ogram
> > > > >> externally (but programming header with 8 address, 4 data, 3 con=
trol wires -
> > > > >> might be too big) or another chip to drive them (I2C I/O expande=
r for
> > > > >> instance and a 3/4 pin header)
> > > > >>
> > > > >>> A device like the Lattice ispMACH 4000 seems a possible candida=
te.
> > > > >>
> > > > >> Does your old design have voltage requirements like 5V capabilit=
y?
> > > > >=20
> > > > > 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.
> > > > >=20
> > > > > Another limitation is that that the preferred programming interfa=
ce 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.
> > > > >=20
> > > > > This is a reason why parallel EEPROM (FLASH) is not an option. Th=
ose
> > > > > devices all require access to all address and data to enter the p=
rogramming
> > > > > sequence. (or do you know a flash that does not require this?)
> > > > > Or use a CPLD to generate those sequences? (based on the states o=
f the free
> > > > > pins?)
> > > > >=20
> > > > What is reading from the EPROM?
> > > > What is the bus speed of the access?
> > > >=20
> > > > I would not be surprised, if you could not implement this with a=20
> > > > microcontroller running at a decent clock frequency.
> > > >=20
> > > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin packa=
ge
> > > > should be small
> > > >=20
> > > > The program will look like this:
> > > > while (1) {
> > > > port =3D memory[pins & 0xff];
> > > > oe =3D (pins & 0x100) ? ON : OFF;
> > > > }
> > > >=20
> > > > AP
> > >=20
> > > I find it interesting that people often feel MCUs are simpler than pr=
ogrammable logic. What your program in particular lacks is the important p=
art, allowing the contents of "memory[]" to be set at manufacturing time. =
I don't see the use of an MCU to be at all simple. In addition to the abov=
e, there is setup code that either needs to be written from scratch by read=
ing the MCU data sheet (starting clocks, initialize I/O banks, brown out de=
tectors, etc., etc...) or by starting with the standard startup code and pa=
ring out what is not needed or appropriate. =20
> > >=20
> > > To me, this is inordinately complex compared to the relatively trivia=
l exercise of creating an HDL ROM which is about as complex as the code abo=
ve and setting the details of the chosen I/O pins to be used. The only rem=
aining issue is to use the vendor tool to initialize this ROM in the compil=
ed code or even in the same way it is done now which I think is done by the=
board itself. =20
> > >=20
> > > Not only is the PLD method simpler, it provides a lot more flexibilit=
y. =20
> >=20
> > if the only thing in your toolbox it hammers, nailing things together a=
lways=20
> > seem like the obvious choice
> >=20
> > at slow speed an mcu could be just as viable, and customizing the array=
could=20
> > be as simple as patching the bin or hex file programmed into the part
>=20
> But you didn't address the additional setup required to write the code fo=
r the MCU. The ones I've used have a *lot* of features that need to be set=
up for the MCU to even run. MCU code is always a lot more complex to desi=
gn with than HDL in my experience. =20
so you have only used big MCUs with piles of peripherals and advanced featu=
res, small 8bitters are usually nothing like that =20
>=20
> "Patching" a hex file is not the way I want to manage configuration data.=
The PLD tools have already dealt with this issue.=20
>=20
doing exactly the same thing, replacing the data
Article: 161329
On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.com =
wrote:
> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com=
:
> > On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.=
com wrote:
> > > torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmai=
l.com:
> > > > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrot=
e:
> > > > > 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 du=
ring the
> > > > > >>> production cycle, in only a few seconds? Something like HDL +=
DATA =3D
> > > > > >>> 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 reco=
mpiling. 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 se=
conds 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/Appli=
cationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devi=
ces.ashx?document_id=3D39086
> > > > > >>
> > > > > >> I suppose another option is a small SPI/I2C flash chip and a C=
PLD 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 c=
ontrol wires -
> > > > > >> might be too big) or another chip to drive them (I2C I/O expan=
der for
> > > > > >> instance and a 3/4 pin header)
> > > > > >>
> > > > > >>> A device like the Lattice ispMACH 4000 seems a possible candi=
date.
> > > > > >>
> > > > > >> Does your old design have voltage requirements like 5V capabil=
ity?
> > > > > >=20
> > > > > > The supply is 5V, but the interface on the reading device is 3V=
3 with 5V
> > > > > > tolerant IO. So adding 3V3 regulation for the memory power shou=
ld work.
> > > > > >=20
> > > > > > Another limitation is that that the preferred programming inter=
face is
> > > > > > through the available connections: Address (8), data (4), contr=
ol (1 +
> > > > > > 1 tied to GND, and VCC rising to VPP). And there are 2 free pin=
s that could
> > > > > > be used as well.
> > > > > >=20
> > > > > > 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?)
> > > > > >=20
> > > > > What is reading from the EPROM?
> > > > > What is the bus speed of the access?
> > > > >=20
> > > > > I would not be surprised, if you could not implement this with a=
=20
> > > > > microcontroller running at a decent clock frequency.
> > > > >=20
> > > > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin pac=
kage
> > > > > should be small
> > > > >=20
> > > > > The program will look like this:
> > > > > while (1) {
> > > > > port =3D memory[pins & 0xff];
> > > > > oe =3D (pins & 0x100) ? ON : OFF;
> > > > > }
> > > > >=20
> > > > > AP
> > > >=20
> > > > I find it interesting that people often feel MCUs are simpler than =
programmable logic. What your program in particular lacks is the important=
part, allowing the contents of "memory[]" to be set at manufacturing time.=
I don't see the use of an MCU to be at all simple. In addition to the ab=
ove, there is setup code that either needs to be written from scratch by re=
ading the MCU data sheet (starting clocks, initialize I/O banks, brown out =
detectors, etc., etc...) or by starting with the standard startup code and =
paring out what is not needed or appropriate. =20
> > > >=20
> > > > To me, this is inordinately complex compared to the relatively triv=
ial exercise of creating an HDL ROM which is about as complex as the code a=
bove and setting the details of the chosen I/O pins to be used. The only r=
emaining issue is to use the vendor tool to initialize this ROM in the comp=
iled code or even in the same way it is done now which I think is done by t=
he board itself. =20
> > > >=20
> > > > Not only is the PLD method simpler, it provides a lot more flexibil=
ity. =20
> > >=20
> > > if the only thing in your toolbox it hammers, nailing things together=
always=20
> > > seem like the obvious choice
> > >=20
> > > at slow speed an mcu could be just as viable, and customizing the arr=
ay could=20
> > > be as simple as patching the bin or hex file programmed into the part
> >=20
> > But you didn't address the additional setup required to write the code =
for the MCU. The ones I've used have a *lot* of features that need to be s=
et up for the MCU to even run. MCU code is always a lot more complex to de=
sign with than HDL in my experience. =20
>=20
>=20
> so you have only used big MCUs with piles of peripherals and advanced fea=
tures, small 8bitters are usually nothing like that =20
>=20
> >=20
> > "Patching" a hex file is not the way I want to manage configuration dat=
a. The PLD tools have already dealt with this issue.=20
> >=20
>=20
> doing exactly the same thing, replacing the data
So there is a tool for patching the hex data? You don't need any startup c=
ode on your small 8 bitter? =20
I think you are being a bit disingenuous about the patching issue. The MCU=
tools I've worked with would require quite a bit of work to replace data i=
n binary code. =20
--=20
Rick C.
+- Get a 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209
Article: 161330Espen Tallaksen <espen.tallaksen@bitvis.no> writes: > Feel free to use RegisterWizard from Bitvis. This is freeware - so no > cost. https://bitvis.no/dev-tools/register-wizard/ We rejected that mostly due to the closed source nature of it but it did seem good. The other option was free and so far has been good enough.Article: 161331
On 2019-03-29 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:
> On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.com wrote:
>> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com:
>> > On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote:
>> > > torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com:
>> > > > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
>> > > > > 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
>> > > >
>> > > > I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate.
>> > > >
>> > > > To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself.
No, 'the board' is connector + PROM on a very small piece of FR4, programmed
in a universal programmer. There is already software generating the data to be
programmed.
And yes, an MCU is a possibility as well. And as I am much more comfortable in
programming MCU's, I think I can handle the software involved for MCU and data
generation. ;-)
But I see a CPLD (or FPGA) as a solution as well and was wondering how I would
approach such a solution. That why I asked in an FPGA group.
>> > > >
>> > > > Not only is the PLD method simpler, it provides a lot more flexibility.
>> > >
>> > > if the only thing in your toolbox it hammers, nailing things together always
>> > > seem like the obvious choice
>> > >
>> > > at slow speed an mcu could be just as viable, and customizing the array could
>> > > be as simple as patching the bin or hex file programmed into the part
>> >
>> > But you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience.
>>
>>
>> so you have only used big MCUs with piles of peripherals and advanced features, small 8bitters are usually nothing like that
>>
>> >
>> > "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue.
>> >
>>
>> doing exactly the same thing, replacing the data
>
> So there is a tool for patching the hex data? You don't need any startup code on your small 8 bitter?
Startup usually comes with the tools. Just start a new project for the
specific controller and everything is set up to defaults and you just have
to write your main() and set the peripherals (which would only be GPIO in
this case). You may want to check the oscillator setup in the startup. And
if you use a higer level tool (like STM32CubeMX for ST controllers), you
can let it generate most of the peripheral init code.
>
> I think you are being a bit disingenuous about the patching issue. The MCU tools I've worked with would require quite a bit of work to replace data in binary code.
>
I think this could be done with the linker. Just add a section with the
calibration data at a fixed address. Or maybe even better (does not require
linker during production), there are plenty of hex file tools and I would
be suprised if there is not one that allow adding a bit of data. And if
there's nothing, writing something like that in C (or Python or Perl or ...)
is not too complex (and I think I even have hex file code in C from old
projects somewhere). But all this is not so relevant for an FPGA group, I
suppose.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Pound for pound, the amoeba is the most vicious animal on earth.
Article: 161332Anssi Saari <as@sci.fi> wrote: > 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. It appears there's a core for making a MAX CPLD look like an I2C EEPROM: https://www.intel.com/content/www/us/en/programmable/documentation/eis1406081952758.html I haven't used these cores, but assume a mux could be interposed between this core and the flash, to allow access to the flash in a parallel manner in addition to via I2C. The OP could put a MAX part on their module, and use the spare two pins on their module to provide an I2C programming interface. The bitfile is programmed at manufacture time (some JTAG pads on the module or pre-program the chips) and the memory can then be field-programmed via the I2C pins on the connector. TheoArticle: 161333
On Friday, March 29, 2019 at 12:12:00 PM UTC-4, Theo wrote: > Anssi Saari <as@sci.fi> wrote: > > 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. > > It appears there's a core for making a MAX CPLD look like an I2C EEPROM: > https://www.intel.com/content/www/us/en/programmable/documentation/eis1406081952758.html > I haven't used these cores, but assume a mux could be interposed between > this core and the flash, to allow access to the flash in a parallel manner > in addition to via I2C. > > The OP could put a MAX part on their module, and use the spare two pins on > their module to provide an I2C programming interface. The bitfile is > programmed at manufacture time (some JTAG pads on the module or pre-program > the chips) and the memory can then be field-programmed via the I2C pins on > the connector. I don't know about others, but I prefer easy to work with packaging. I find most FPGAs come in hard (for me) to use chip scale or BGA packages (very large pin counts). The Lattice parts at least are available in QFN packages. -- Rick C. ++ Get a 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209Article: 161334
Den 2019-03-29 kl. 01:17, skrev gnuarm.deletethisbit@gmail.com:
> On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.com wrote:
>> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com:
>>> On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote:
>>>> torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com:
>>>>> On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
>>>>>> 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
>>>>>
>>>>> I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate.
>>>>>
>>>>> To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself.
>>>>>
>>>>> Not only is the PLD method simpler, it provides a lot more flexibility.
>>>>
>>>> if the only thing in your toolbox it hammers, nailing things together always
>>>> seem like the obvious choice
>>>>
>>>> at slow speed an mcu could be just as viable, and customizing the array could
>>>> be as simple as patching the bin or hex file programmed into the part
>>>
>>> But you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience.
>>
>>
>> so you have only used big MCUs with piles of peripherals and advanced features, small 8bitters are usually nothing like that
>>
>>>
>>> "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue.
>>>
>>
>> doing exactly the same thing, replacing the data
>
> So there is a tool for patching the hex data? You don't need any startup code on your small 8 bitter?
>
> I think you are being a bit disingenuous about the patching issue. The MCU tools I've worked with would require quite a bit of work to replace data in binary code.
>
If you never used a micro, you may have a problem.
If you have used a specific micro, then you are likely to have setup code.
The ROM code is best expressed in C.
const uint8_t memory[256] = {
0x00, 0x01, 0x02, 0x03, ...
};
You get a state of the art C compiler/debugger from IAR free of charge
for these types of applications.
If you are not in a hurry, you can implement a bitbanged USART in three
pins in the micro.
You send an address, as an 8 bit byte, and the micro responds with the data.
The Micro is going to be way cheaper than a programmable logic device
if there is any volume at all behind such a request.
You can also get much much smaller packages with micros than with
programmable logic.
AP
Article: 161335
On Friday, March 29, 2019 at 6:52:14 PM UTC-4, A.P.Richelieu wrote:
> Den 2019-03-29 kl. 01:17, skrev gnuarm.deletethisbit@gmail.com:
> > On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.=
com wrote:
> >> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.=
com:
> >>> On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmai=
l.com wrote:
> >>>> torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gma=
il.com:
> >>>>> On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrot=
e:
> >>>>>> 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 a=
n HDL
> >>>>>>>>> design. But are there options to generate these bitstreams duri=
ng the
> >>>>>>>>> production cycle, in only a few seconds? Something like HDL + D=
ATA =3D
> >>>>>>>>> BITSTREAM. And then burn the resulting bitsream in the device.
> >>>>>>>>
> >>>>>>>> Intel Quartus has an 'Update Memory Initialization File' step wh=
ere you can
> >>>>>>>> change the memory contents of an existing project without recomp=
iling. I
> >>>>>>>> don't know how much project scaffolding you'd need (you still ne=
ed to run
> >>>>>>>> the Assembler step to generate bitfiles afterwards, so I don't t=
hink you can
> >>>>>>>> edit an existing bitfile). It's not super quick (maybe ten seco=
nds 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/Applica=
tionNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Device=
s.ashx?document_id=3D39086
> >>>>>>>>
> >>>>>>>> I suppose another option is a small SPI/I2C flash chip and a CPL=
D that reads
> >>>>>>>> the contents in at powerup time. Or a NOR flash that you can pr=
ogram
> >>>>>>>> externally (but programming header with 8 address, 4 data, 3 con=
trol wires -
> >>>>>>>> might be too big) or another chip to drive them (I2C I/O expande=
r for
> >>>>>>>> instance and a 3/4 pin header)
> >>>>>>>>
> >>>>>>>>> A device like the Lattice ispMACH 4000 seems a possible candida=
te.
> >>>>>>>>
> >>>>>>>> Does your old design have voltage requirements like 5V capabilit=
y?
> >>>>>>>
> >>>>>>> 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 interfa=
ce 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. Th=
ose
> >>>>>>> devices all require access to all address and data to enter the p=
rogramming
> >>>>>>> sequence. (or do you know a flash that does not require this?)
> >>>>>>> Or use a CPLD to generate those sequences? (based on the states o=
f 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 pack=
age
> >>>>>> should be small
> >>>>>>
> >>>>>> The program will look like this:
> >>>>>> while (1) {
> >>>>>> port =3D memory[pins & 0xff];
> >>>>>> oe =3D (pins & 0x100) ? ON : OFF;
> >>>>>> }
> >>>>>>
> >>>>>> AP
> >>>>>
> >>>>> I find it interesting that people often feel MCUs are simpler than =
programmable logic. What your program in particular lacks is the important=
part, allowing the contents of "memory[]" to be set at manufacturing time.=
I don't see the use of an MCU to be at all simple. In addition to the ab=
ove, there is setup code that either needs to be written from scratch by re=
ading the MCU data sheet (starting clocks, initialize I/O banks, brown out =
detectors, etc., etc...) or by starting with the standard startup code and =
paring out what is not needed or appropriate.
> >>>>>
> >>>>> To me, this is inordinately complex compared to the relatively triv=
ial exercise of creating an HDL ROM which is about as complex as the code a=
bove and setting the details of the chosen I/O pins to be used. The only r=
emaining issue is to use the vendor tool to initialize this ROM in the comp=
iled code or even in the same way it is done now which I think is done by t=
he board itself.
> >>>>>
> >>>>> Not only is the PLD method simpler, it provides a lot more flexibil=
ity.
> >>>>
> >>>> if the only thing in your toolbox it hammers, nailing things togethe=
r always
> >>>> seem like the obvious choice
> >>>>
> >>>> at slow speed an mcu could be just as viable, and customizing the ar=
ray could
> >>>> be as simple as patching the bin or hex file programmed into the par=
t
> >>>
> >>> But you didn't address the additional setup required to write the cod=
e for the MCU. The ones I've used have a *lot* of features that need to be=
set up for the MCU to even run. MCU code is always a lot more complex to =
design with than HDL in my experience.
> >>
> >>
> >> so you have only used big MCUs with piles of peripherals and advanced =
features, small 8bitters are usually nothing like that
> >>
> >>>
> >>> "Patching" a hex file is not the way I want to manage configuration d=
ata. The PLD tools have already dealt with this issue.
> >>>
> >>
> >> doing exactly the same thing, replacing the data
> >=20
> > So there is a tool for patching the hex data? You don't need any start=
up code on your small 8 bitter?
> >=20
> > I think you are being a bit disingenuous about the patching issue. The=
MCU tools I've worked with would require quite a bit of work to replace da=
ta in binary code.
> >=20
> If you never used a micro, you may have a problem.
> If you have used a specific micro, then you are likely to have setup code=
.
>=20
> The ROM code is best expressed in C.
> const uint8_t memory[256] =3D {
> 0x00, 0x01, 0x02, 0x03, ...
> };
>=20
> You get a state of the art C compiler/debugger from IAR free of charge
> for these types of applications.
>=20
> If you are not in a hurry, you can implement a bitbanged USART in three=
=20
> pins in the micro.
> You send an address, as an 8 bit byte, and the micro responds with the da=
ta.
>=20
> The Micro is going to be way cheaper than a programmable logic device
> if there is any volume at all behind such a request.
>=20
> You can also get much much smaller packages with micros than with=20
> programmable logic.
Not if the design is pin defined. This design can't be done with an 8 pin =
package. =20
Cost depends on many things and some FPGAs are very inexpensive. Having th=
e simplest production solution is a great start. So far FPGAs are the only=
solution that actually provides a clear and simple method of being program=
med with the configuration data in production without issues. But I should=
n't say that because I don't truly understand all the issues the OP has. I=
do know that the FPGA will handle them all as presently understood. The M=
CU will require some work to make that happen I believe.=20
--=20
Rick C.
--- Get a 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209
Article: 161336
Den 2019-03-30 kl. 02:48, skrev gnuarm.deletethisbit@gmail.com:
> On Friday, March 29, 2019 at 6:52:14 PM UTC-4, A.P.Richelieu wrote:
>> Den 2019-03-29 kl. 01:17, skrev gnuarm.deletethisbit@gmail.com:
>>> On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.com wrote:
>>>> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com:
>>>>> On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote:
>>>>>> torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com:
>>>>>>> On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
>>>>>>>> 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
>>>>>>>
>>>>>>> I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate.
>>>>>>>
>>>>>>> To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself.
>>>>>>>
>>>>>>> Not only is the PLD method simpler, it provides a lot more flexibility.
>>>>>>
>>>>>> if the only thing in your toolbox it hammers, nailing things together always
>>>>>> seem like the obvious choice
>>>>>>
>>>>>> at slow speed an mcu could be just as viable, and customizing the array could
>>>>>> be as simple as patching the bin or hex file programmed into the part
>>>>>
>>>>> But you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience.
>>>>
>>>>
>>>> so you have only used big MCUs with piles of peripherals and advanced features, small 8bitters are usually nothing like that
>>>>
>>>>>
>>>>> "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue.
>>>>>
>>>>
>>>> doing exactly the same thing, replacing the data
>>>
>>> So there is a tool for patching the hex data? You don't need any startup code on your small 8 bitter?
>>>
>>> I think you are being a bit disingenuous about the patching issue. The MCU tools I've worked with would require quite a bit of work to replace data in binary code.
>>>
>> If you never used a micro, you may have a problem.
>> If you have used a specific micro, then you are likely to have setup code.
>>
>> The ROM code is best expressed in C.
>> const uint8_t memory[256] = {
>> 0x00, 0x01, 0x02, 0x03, ...
>> };
>>
>> You get a state of the art C compiler/debugger from IAR free of charge
>> for these types of applications.
>>
>> If you are not in a hurry, you can implement a bitbanged USART in three
>> pins in the micro.
>> You send an address, as an 8 bit byte, and the micro responds with the data.
>>
>> The Micro is going to be way cheaper than a programmable logic device
>> if there is any volume at all behind such a request.
>>
>> You can also get much much smaller packages with micros than with
>> programmable logic.
>
> Not if the design is pin defined. This design can't be done with an 8 pin package.
>
> Cost depends on many things and some FPGAs are very inexpensive. Having the simplest production solution is a great start. So far FPGAs are the only solution that actually provides a clear and simple method of being programmed with the configuration data in production without issues. But I shouldn't say that because I don't truly understand all the issues the OP has. I do know that the FPGA will handle them all as presently understood. The MCU will require some work to make that happen I believe.
>
The configuration file is a simple text file which gets included in the
build. It is easily generated from a hex file, if that is a need.
You can program the microcontroller and the FPGA before you mount it to
the PCB. Otherwise you program both using JTAG.
There is ZERO issues in programming a micro. It is well known thing.
There will be some fallout with BOTH.
If there is a need to update the contents in the field, you can do so
using a serial port = 2 pin.
With a need for 13 I/Os, for the ROM interface, a 24 pin QFN package (4
x 4 mm) should do. Smallest FPGA is 3 x the price.
It is going to cost around $1.25 @ 1 piece @ Digikey.
The smallest FPGA is 3 x the price.
The power consumption is going to be a fraction of that of an FPGA.
The only thing that needs to be checked if the solution is fast enough.
AP
Article: 161337
Den 2019-03-30 kl. 08:12, skrev gnuarm.deletethisbit@gmail.com:
> On Saturday, March 30, 2019 at 12:54:36 AM UTC-4, A.P.Richelieu wrote:
>> Den 2019-03-30 kl. 02:48, skrev gnuarm.deletethisbit@gmail.com:
>>> On Friday, March 29, 2019 at 6:52:14 PM UTC-4, A.P.Richelieu wrote:
>>>> Den 2019-03-29 kl. 01:17, skrev gnuarm.deletethisbit@gmail.com:
>>>>> On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.com wrote:
>>>>>> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com:
>>>>>>> On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote:
>>>>>>>> torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com:
>>>>>>>>> On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate.
>>>>>>>>>
>>>>>>>>> To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself.
>>>>>>>>>
>>>>>>>>> Not only is the PLD method simpler, it provides a lot more flexibility.
>>>>>>>>
>>>>>>>> if the only thing in your toolbox it hammers, nailing things together always
>>>>>>>> seem like the obvious choice
>>>>>>>>
>>>>>>>> at slow speed an mcu could be just as viable, and customizing the array could
>>>>>>>> be as simple as patching the bin or hex file programmed into the part
>>>>>>>
>>>>>>> But you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience.
>>>>>>
>>>>>>
>>>>>> so you have only used big MCUs with piles of peripherals and advanced features, small 8bitters are usually nothing like that
>>>>>>
>>>>>>>
>>>>>>> "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue.
>>>>>>>
>>>>>>
>>>>>> doing exactly the same thing, replacing the data
>>>>>
>>>>> So there is a tool for patching the hex data? You don't need any startup code on your small 8 bitter?
>>>>>
>>>>> I think you are being a bit disingenuous about the patching issue. The MCU tools I've worked with would require quite a bit of work to replace data in binary code.
>>>>>
>>>> If you never used a micro, you may have a problem.
>>>> If you have used a specific micro, then you are likely to have setup code.
>>>>
>>>> The ROM code is best expressed in C.
>>>> const uint8_t memory[256] = {
>>>> 0x00, 0x01, 0x02, 0x03, ...
>>>> };
>>>>
>>>> You get a state of the art C compiler/debugger from IAR free of charge
>>>> for these types of applications.
>>>>
>>>> If you are not in a hurry, you can implement a bitbanged USART in three
>>>> pins in the micro.
>>>> You send an address, as an 8 bit byte, and the micro responds with the data.
>>>>
>>>> The Micro is going to be way cheaper than a programmable logic device
>>>> if there is any volume at all behind such a request.
>>>>
>>>> You can also get much much smaller packages with micros than with
>>>> programmable logic.
>>>
>>> Not if the design is pin defined. This design can't be done with an 8 pin package.
>>>
>>> Cost depends on many things and some FPGAs are very inexpensive. Having the simplest production solution is a great start. So far FPGAs are the only solution that actually provides a clear and simple method of being programmed with the configuration data in production without issues. But I shouldn't say that because I don't truly understand all the issues the OP has. I do know that the FPGA will handle them all as presently understood. The MCU will require some work to make that happen I believe.
>>>
>>
>> The configuration file is a simple text file which gets included in the
>> build. It is easily generated from a hex file, if that is a need.
>> You can program the microcontroller and the FPGA before you mount it to
>> the PCB. Otherwise you program both using JTAG.
>> There is ZERO issues in programming a micro. It is well known thing.
>> There will be some fallout with BOTH.
>>
>> If there is a need to update the contents in the field, you can do so
>> using a serial port = 2 pin.
>>
>> With a need for 13 I/Os, for the ROM interface, a 24 pin QFN package (4
>> x 4 mm) should do. Smallest FPGA is 3 x the price.
>>
>> It is going to cost around $1.25 @ 1 piece @ Digikey.
>> The smallest FPGA is 3 x the price.
>> The power consumption is going to be a fraction of that of an FPGA.
>>
>> The only thing that needs to be checked if the solution is fast enough.
>
> The issue is that the programming file needs to be modified with calibration data for each device being programmed. This process is well defined for FPGAs since it is common to need to load block rams or in this case User Flash. In addition there are particular methods of loading the User Flash.
>
> The point is the loading of configuration data can be easily integrated into the typical programming process for the FPGA. This is not as straightforward for the MCU where you need to perform a build rather than just loading the configuration data.
>
> Your information about FPGAs is not so current, especially the power consumption. You clearly have not worked with the lower power devices which are available. There are devices that have double digit microamp power levels if not being clocked at high rates. The devices I have pointed to are available in QFN packages in addition to very tiny chip scale packages.
>
> FPGA packaging is one of my pet peaves. The focus in smaller FPGAs seems to be package size to fit mobile apps. So while there are very tiny packages available, they don't suit my apps. But you can't say small packages aren't available.
>
Once you have programmed the microcontroller, you use a write pin to
program the part, and a read pin to read out the part.
These things can be connected to DMA, for quite high speed.
Since the reads were "slow", I bet this is good enough.
Piece of cake.
The build to add an additional memory array of 128 bytes takes a
fraction of a second. It is not complex. It is well known technology.
To say that this is not straightforward shows that you know little about
MCUs.
AP
Article: 161338In article <q7nbpc$1v9l$1@gioia.aioe.org>, aprichelieu@gmail.com says... > > Once you have programmed the microcontroller, you use a write pin to > program the part, and a read pin to read out the part. > These things can be connected to DMA, for quite high speed. > Since the reads were "slow", I bet this is good enough. > Piece of cake. > > The build to add an additional memory array of 128 bytes takes a > fraction of a second. It is not complex. It is well known technology. > To say that this is not straightforward shows that you know little about > MCUs. > > AP > The first thing that went through my mind when I saw the original post was "microchip PIC" - the size of a full stop. I just assumed I'd missunderstood since this was an FPGA group. I'd concur with the other posters - microprocessor is the way to go. I'd recommend a download of their parts selector software (free) and have a browse. FPGA's require far too much work for everyday tasks such as this. -- john ========================= http://johntech.co.uk =========================Article: 161339
Den 2019-03-30 kl. 11:00, skrev john: > In article <q7nbpc$1v9l$1@gioia.aioe.org>, aprichelieu@gmail.com says... >> >> Once you have programmed the microcontroller, you use a write pin to >> program the part, and a read pin to read out the part. >> These things can be connected to DMA, for quite high speed. >> Since the reads were "slow", I bet this is good enough. >> Piece of cake. >> >> The build to add an additional memory array of 128 bytes takes a >> fraction of a second. It is not complex. It is well known technology. >> To say that this is not straightforward shows that you know little about >> MCUs. >> >> AP >> > > The first thing that went through my mind when I saw the original post > was "microchip PIC" - the size of a full stop. > I just assumed I'd missunderstood since this was an FPGA group. > > I'd concur with the other posters - microprocessor is the way to go. > I'd recommend a download of their parts selector software (free) and have a > browse. > FPGA's require far too much work for everyday tasks such as this. > The Event System originally implemented in the AVR is probably quite useful for this application. It is available in some Cortex-M parts as well where the NMI can be used for almost no delay response. APArticle: 161340
Benjamin Couillard <benjamin.couillard@gmail.com> writes: > Le mercredi 27 mars 2019 04:03:00 UTC-4, Anssi Saari a écrit : >> 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? >> > > 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 code. The typo is corrected in a later post. Thanks. Well, it looks like it will take some work to get from the snippets to a working implementation but I'll see what I can do with it.Article: 161341
Hi,
I am trying to design a state machine for bitslip function but simulations dont seem to be correct. I cant figure out where the bug is.
here is the code and test bench.
module bitsliplogic(
CLOCK,
RESET,
DATAIN,
SYNC_PATTERN,
BITSLIP,
BITSLIP_DONE
);
parameter data_width = 10;
parameter counter_width_0 = 16;
parameter DELAY_0 = 10; //10 clock cycle
input CLOCK;
input RESET;
input [data_width-1:0] DATAIN;
input [data_width-1:0] SYNC_PATTERN;
output BITSLIP;
output BITSLIP_DONE;
//State Machine
parameter IDLE = 7'b0000001;
parameter CHECK_SYNC = 7'b0000010;
parameter ASSERT_BITSLIP = 7'b0000100;
parameter WAIT_0 = 7'b0001000;
parameter DEASSERT_BITSLIP = 7'b0010000;
parameter BITSLIP_SEQ_DONE = 7'b0100000;
///////////////////////////////////////////////////////////////////////////////////////////////////////////
reg [counter_width_0 - 1:0] counter_0;
reg [6:0] state, next;
//register for State Machine
reg bitslip_sig;
reg bitslip_reg;
reg bitslip_done_reg;
reg start_count;
reg [counter_width_0-1:0] count_val;
wire count_done;
///////////////////////////////////////////////////////////////////////////////////////////////////////////
assign count_done = (counter_0 == count_val)? 1'b1 : 1'b0;
//assignment for output
assign BITSLIP = bitslip_reg;
assign BITSLIP_DONE = bitslip_done_reg;
///////////////////////////////////////////////////////////////////////////////////////////////////////////
always @(posedge CLOCK or posedge RESET)
if (RESET)
counter_0 <= {counter_width_0{1'b0}};
else if (count_done)
counter_0 <= {counter_width_0{1'b0}};
else if (start_count)
counter_0 <= counter_0 + 1'b1;
always @(posedge CLOCK or posedge RESET)
if (RESET)
bitslip_reg <= 1'b0;
else if ((state == ASSERT_BITSLIP) || (state == DEASSERT_BITSLIP))
bitslip_reg <= bitslip_sig;
always @(posedge CLOCK or posedge RESET)
if (RESET)
bitslip_done_reg <= 1'b0;
else if (state == BITSLIP_SEQ_DONE)
bitslip_done_reg <= 1'b1;
else
bitslip_done_reg <= 1'b0;
///////////////////////////////////////////////////////////////////////////////////////////////////////////
//State Machine
always @(posedge CLOCK or posedge RESET)
if (RESET) begin
state <= IDLE;
end
else begin
state <= next;
end
always @(*)
begin
next = IDLE;
bitslip_sig = 1'b0;
start_count = 1'b0;
count_val = 16'h0000;
case (state)
IDLE : begin
next = CHECK_SYNC;
end
CHECK_SYNC: begin
if (DATAIN == SYNC_PATTERN)
next = BITSLIP_SEQ_DONE;
else if (DATAIN == 16'h0000)
next = CHECK_SYNC;
else
next = ASSERT_BITSLIP;
end
ASSERT_BITSLIP: begin
bitslip_sig = 1'b1;
next = WAIT_0;
end
WAIT_0: begin
start_count = 1'b1;
count_val = DELAY_0; //wait for all 10 bits of data to be processed. that is what delay_0 is doing
if (count_done)
next = DEASSERT_BITSLIP;
else
next = WAIT_0;
end
DEASSERT_BITSLIP: begin
bitslip_sig = 1'b0;
next = CHECK_SYNC;
end
BITSLIP_SEQ_DONE: begin
next = BITSLIP_SEQ_DONE;
end
default: begin
next = IDLE;
end
endcase
end
///////////////////////////////////////////////////////////////////////////////////////////////////////////
endmodule
test bench
`timescale 1ns / 1ns
module ttb10 ;
parameter BITSLIP_SEQ_DONE = 7'b0100000 ;
parameter WAIT_0 = 7'b0001000 ;
parameter ASSERT_BITSLIP = 7'b0000100 ;
parameter DEASSERT_BITSLIP = 7'b0010000 ;
parameter data_width = 10 ;
parameter CHECK_SYNC = 7'b0000010 ;
parameter IDLE = 7'b0000001 ;
parameter DELAY_0 = 9 ;
parameter counter_width_0 = 16 ;
wire BITSLIP_DONE ;
reg CLOCK ;
reg [data_width-1:0] DATAIN ;
reg [data_width-1:0] SYNC_PATTERN ;
wire BITSLIP ;
reg RESET ;
bitsliplogic #( BITSLIP_SEQ_DONE , WAIT_0 , ASSERT_BITSLIP , DEASSERT_BITSLIP , data_width , CHECK_SYNC , IDLE , DELAY_0 , counter_width_0 )
DUT (
.BITSLIP_DONE (BITSLIP_DONE ) ,
.CLOCK (CLOCK ) ,
.DATAIN (DATAIN ) ,
.SYNC_PATTERN (SYNC_PATTERN ) ,
.BITSLIP (BITSLIP ) ,
.RESET (RESET ) );
reg [9 : 0] \VARDATAIN ;
// "Clock Pattern" : dutyCycle = 50
// Start Time = 0 ns, End Time = 1 us, Period = 20 ns
initial
begin
CLOCK = 1'b0 ;
# 10 ;
// 10 ns, single loop till start period.
repeat(99)
begin
CLOCK = 1'b1 ;
#10 CLOCK = 1'b0 ;
#10 ;
// 990 ns, repeat pattern in loop.
end
CLOCK = 1'b1 ;
# 10 ;
// dumped values till 1 us
end
// "Constant Pattern"
// Start Time = 0 ns, End Time = 1 us, Period = 0 ns
initial
begin
RESET = 1'b1 ;
#400 RESET = 1'b0 ;
# 2000 ;
// dumped values till 1 us
end
// "Counter Pattern"(Range-Up) : step = 1 Range(0000000000-1111111111)
// Start Time = 0 ns, End Time = 1 us, Period = 50 ns
initial
begin
DATAIN = 10'b0000000000 ;
# 120 DATAIN = 10'b0000000000 ;
# 120 DATAIN = 10'b0010111110 ;
# 120 DATAIN = 10'b0001011111;
# 120 DATAIN = 10'b1000101111;
# 120 DATAIN = 10'b1100010111;
# 120 DATAIN = 10'b1110001011;
# 120 DATAIN = 10'b1111000101;
# 120 DATAIN = 10'b1111100010;
# 120 DATAIN = 10'b0111110001;
# 120 DATAIN = 10'b1011111000;
# 120 DATAIN = 10'h17c;
# 50 ;
// dumped values till 1 us
end
// "Constant Pattern"
// Start Time = 0 ns, End Time = 1 us, Period = 0 ns
initial
begin
SYNC_PATTERN = 10'h17c ;
# 1000 ;
// dumped values till 1 us
end
initial
#2000 $stop;
endmodule
Article: 161342Am Donnerstag, 28. M=C3=A4rz 2019 13:43:07 UTC+1 schrieb Stef: > 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? [..] > A device like the Lattice ispMACH 4000 seems a possible candidate. Many FPGAs require an external EEPROM for storing the Bitfile. All those wi= ll be no choice for you. Whats left is in fact some old CPLDs, Lattice and Microsemi which all use i= nternal Flash. The CPLDs would be in many occasions too small to store 1024= bits random content.=20 I understand it is something like 256 times 4 bit. This means you have 8 bi= t address for 4 bit result.=20 A function calculating 4 bits result from 8 bit address can be either very = simple (eg: Bit0=3Dnot Adress(0), bit1=3DAddress(0), bit2=3Daddress(1) xor = address(2), bit3 =3D address(3) and address(4)) or very complex (example le= ft to you). Due to Fan-In/Fan-Out constraints a function looking simple can simple expl= ode in size, my experience says you cannot say on first glance how easy or = complex a table transfers into a combinatorical circuit. So the question if you have 10 different tables which of those require what= size of combinatoric is hard to answer before implementing it. On the other hand most FPGAs packages might be too large in size for your b= oard design, if a simple EEPROM is allready too large. No idea what cou can= accept. You might want to check out the Microsemi ProAsic3 technology which provide= s an 1k EEPROM for user access. The smallest package would be the A3PN010 i= n QN48 (6x6 mm) regards ThomasArticle: 161343
On Tuesday, April 2, 2019 at 7:19:09 AM UTC-4, Thomas Stanka wrote: > Am Donnerstag, 28. M=C3=A4rz 2019 13:43:07 UTC+1 schrieb Stef: > > We have a product that includes a small parallel OTP memory. These devi= ces > > 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? > [..] > > A device like the Lattice ispMACH 4000 seems a possible candidate. >=20 > Many FPGAs require an external EEPROM for storing the Bitfile. All those = will be no choice for you. >=20 > Whats left is in fact some old CPLDs, Lattice and Microsemi which all use= internal Flash. The CPLDs would be in many occasions too small to store 10= 24 bits random content.=20 >=20 > I understand it is something like 256 times 4 bit. This means you have 8 = bit address for 4 bit result.=20 > A function calculating 4 bits result from 8 bit address can be either ver= y simple (eg: Bit0=3Dnot Adress(0), bit1=3DAddress(0), bit2=3Daddress(1) xo= r address(2), bit3 =3D address(3) and address(4)) or very complex (example = left to you). >=20 > Due to Fan-In/Fan-Out constraints a function looking simple can simple ex= plode in size, my experience says you cannot say on first glance how easy o= r complex a table transfers into a combinatorical circuit. > So the question if you have 10 different tables which of those require wh= at size of combinatoric is hard to answer before implementing it. >=20 > On the other hand most FPGAs packages might be too large in size for your= board design, if a simple EEPROM is allready too large. No idea what cou c= an accept. >=20 > You might want to check out the Microsemi ProAsic3 technology which provi= des an 1k EEPROM for user access. The smallest package would be the A3PN010= in QN48 (6x6 mm) >=20 > regards Thomas You seem to have not read most of the posts in this thread. There have bee= n specific FPGAs mentioned which will do the job the OP needs. He seems to= prefer an MCU approach because he is more familiar with MCUs than FPGAs. = =20 --=20 Rick C. -+- Get a 1,000 miles of free Supercharging -+- Tesla referral code - https://ts.la/richard11209Article: 161344
On 2019-04-03 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga: > On Tuesday, April 2, 2019 at 7:19:09 AM UTC-4, Thomas Stanka wrote: >> >> Many FPGAs require an external EEPROM for storing the Bitfile. All those will be no choice for you. A dual package solution is not prefered, but if the packages are small enough, it might fit. Double sided placement could be a last resort as long as the bottom components are <= 1mm high. >> >> On the other hand most FPGAs packages might be too large in size for your board design, if a simple EEPROM is allready too large. No idea what cou can accept. A TSOP EEPROM would be a good mechanical fit, but unfortunately it is electrically unsuitable as you need access to all address and data pins for programming. I managed to get an SOIC28 (17.9 x 10.3 mm) on the board after reducing some clearances and pad sizes, but that relies on the connector and memory pins 'interleaving' a little (pitch 2.54 and 1.27 mm). So generically I would say the maximum size is 18 x 9 mm >> You might want to check out the Microsemi ProAsic3 technology which provides an 1k EEPROM for user access. The smallest package would be the A3PN010 in QN48 (6x6 mm) That would fit mechanically. > You seem to have not read most of the posts in this thread. There have been specific FPGAs mentioned which will do the job the OP needs. He seems to prefer an MCU approach because he is more familiar with MCUs than FPGAs. It is not that I prefer an MCU approach, but I am indeed more comfortable with MCU's. And if I go that way and need help, I think it's best not to ask in an FPGA group. ;-) There are other issues against the MCU approach. One of them is that it may (this is not sure) be harder for certification than a CPLD solution. For now I am still trying to find all possible solutions (and still hoping for a suitable memory device to pop up :-( ) so I can come up with a good overview of solutions. The overview should include all costs and effort for components, development, tools, certification, in-line programming, etc. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Every man takes the limits of his own field of vision for the limits of the world. -- SchopenhauerArticle: 161345
What is required: - access time - power supply voltage - interface lines Addr/Data/CS What is the oryginal chip? Reagards JarekC Użytkownik "Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> napisał w wiadomości news:nnd$093f4a46$3b21e82e@963e990d8e91a0cc... | 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: 161346
On Thu, 28 Mar 2019 13:28:46 +0100 Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: > We have a product that includes a small parallel OTP memory. [snip] > > A device like the Lattice ispMACH 4000 seems a possible candidate. You seem to be right. I tried a random pattern in a Lattice 4064 part, and in one of the small Xilinx parts, both fitted, but more testing is needed to see what proportion of possible patterns would fit. Part size from 4x4mm BGA to 7x7mm TQFP. Six connections are needed for flashing, could be pins, holes, or pads. If it is a microprocessor system, and you have firmware build access, I would use a 1kx8 I2C eeprom in SOT23-5 package. As others have noted, perhaps there is not enough detail in your spec to suggest optimum solutions. Perhaps you are just doing re- calibration and need to build a pin-compatible solution? Jan Coombs --Article: 161347
If anyone is interested I just got round to putting up a nexys Video artix-7 board on ebay. This is a private not trade sale. https://www.ebay.co.uk/itm/Development-Board-Nexys-Video-Artix-7-FPGA-for-M ultimedia-Applications-etc/283452707848?hash=item41ff191408:g:QzwAAOSwj1 VctIxm Feel free to contact me if you have questions but it pretty much speaks for itself. -- john ========================= http://johntech.co.uk =========================Article: 161348
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 21 =D0=BE=D0=BA=D1=82=D1=8F=D0= =B1=D1=80=D1=8F 2008 =D0=B3., 6:40:26 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Bryan =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: > I think the MultiBoot feature available in Xilinx FPGAs is especially > useful for field updates. MultiBoot allows you to update the FPGA > while maintaining a failsafe image. Avnet has an example application > note showing how to do this, updating the secondary image in serial > Flash with a new image arriving over ethernet. >=20 > "S3A1800DSP Serial Flash Bistream Update over Ethernet" at > https://www.em.avnet.com/common/filetree/0%2C2740%2CRID%3D&CID%3D42106&CC= D%3DUSA&SID%3D32214&DID%3DDF2&SRT%3D1&LID%3D32232&PRT%3D0&PVW%3D&PNT%3D&BID= %3DDF2&CTP%3DEVK%2C00.html?ACD=3D3 >=20 > Bryan >=20 > On Oct 19, 9:25=C2=A0am, Jan <1...@2.3> wrote: > > Dear all, > > > > What are the smartest way to make a solo FPGA project capable of field > > updates? I'm very new in the FPGA world so I don't much about the > > practical use of them. Normally when I uses microcontrollers I make the= m > > updateble via USB, serial or SD cards. > > > > What techniques are possible when I want to avoid having a uP in the > > project. > > > > My target is a Xilinx Spartan 3A or 3AN > > > > Regards > > =C2=A0 =C2=A0 Jan Hi, nobody knows, how to get this reference design. The link doesn't workArticle: 161349
On Thursday, 18 April 2019 12:38:42 UTC+2, polovn...@gmail.com wrote: > =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 21 =D0=BE=D0=BA=D1=82=D1=8F= =D0=B1=D1=80=D1=8F 2008 =D0=B3., 6:40:26 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0= =B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Bryan =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0=D0=BB: > > I think the MultiBoot feature available in Xilinx FPGAs is especially > > useful for field updates. MultiBoot allows you to update the FPGA > > while maintaining a failsafe image. Avnet has an example application > > note showing how to do this, updating the secondary image in serial > > Flash with a new image arriving over ethernet. > >=20 > > "S3A1800DSP Serial Flash Bistream Update over Ethernet" at > > https://www.em.avnet.com/common/filetree/0%2C2740%2CRID%3D&CID%3D42106&= CCD%3DUSA&SID%3D32214&DID%3DDF2&SRT%3D1&LID%3D32232&PRT%3D0&PVW%3D&PNT%3D&B= ID%3DDF2&CTP%3DEVK%2C00.html?ACD=3D3 > >=20 > > Bryan > >=20 > > On Oct 19, 9:25=C2=A0am, Jan <1...@2.3> wrote: > > > Dear all, > > > > > > What are the smartest way to make a solo FPGA project capable of fiel= d > > > updates? I'm very new in the FPGA world so I don't much about the > > > practical use of them. Normally when I uses microcontrollers I make t= hem > > > updateble via USB, serial or SD cards. > > > > > > What techniques are possible when I want to avoid having a uP in the > > > project. > > > > > > My target is a Xilinx Spartan 3A or 3AN >=20 > Hi, nobody knows, how to get this reference design. The link doesn't work I have simply searched for "S3A1800DSP Serial Flash Bistream Update over Ethernet", here is the first result I get: <https://forums.xilinx.com/t5/Embedded-Development-Tools/Bootloader-for-Spa= rtan-6-with-SPI-FLash/td-p/158360> That said, it is very bad etiquette to resurrect old threads: open a new on= e, possibly with links to any old posts or whatever is relevant... HTH and good luck, Julio
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