Generate multiple binary files on ISE with different serial number - vhdl

I want to version all the boards on which I put a version of my FPGA.
Each board shall have a different serial number stored in an internal ROM. It's basically a 10 digits number (ie: 0123456789).
After generating the binary file , how can I modify it to increment the number without damaging the FPGA and its behavior?
Have anyone already done this before?

Which FPGA are you using? For Xilinx Devices you can use the USR_ACCESS register that can be set when creating the bitstream file. Limited up to 32bits of data.
https://www.xilinx.com/support/documentation/application_notes/xapp497_usr_access.pdf

Related

Asking about FPGA design with IP cores

I am new to Verilog, also FPGA, and currently working on the project involved them. I am conducting channel coding blocks for a broadcast standard DVB-S2 including BCH encoder, scrambler and BBheader insertion. I'm using Vivado 2015.4 for hardware design and Zynq-7000 ZC702 evaluation kit, and I wonder:
Is it necessary to connect my IP cores which are the blocks with the Processing unit(for Vivado 2015.4 is ZynQ-7000) for implementation?
Do I have to generate the bit stream to export it to SDK for software developing. I really don't know what is the purpose for exporting to SDK when you all have designed your IP on Vivado.
Can anyone give me an example flow of designing a BBheader insertion(which is more like adding the flags bits in front of the desired data for recognition).
What I just want is to read the data from Block ROM and encode those data (which is video but then converted into bin or hex file) with my IP cores.
1) If you intend to make use of the processor to run software, you need to connect it to the IP block somehow, or you'll have no way of interfacing the two.
2) Exporting the bitfile to the SDK tells the SDK which pins of the CPU are being used, which is necessary knowledge for development.
3) Though I can't give you a specific answer for this, I suggest reading the IP core documentation and it might naturally become clear.

Array of values loaded through UART in VHDL

I am working on a project in VHDL wich includes mutliplying matrices. I would like to be able to load data from PC to arrays on FPGA using UART. I am only making my first bigger steps in VHDL and I am not sure if I am taking the right attitude.
I wanted to declare an array of integer signals, and then implement UART to receive data form PC and load it into those signals. However, I can't use for-loop for that, as it will be synthesised to load data parallelly (which is impossible, because values will be comming from PC one after another, using serial port.) And because matrices may be various sizes, in order to assign signals one by one I would need to write lots of specific code (and it appears to be a bad practice to me.)
Is the idea to use an array of signals and load data to those signals through UART realizable? And if my approach is entirely wrong, how could I achieve that?
What you want is doable but you will probably need to design a kind of hardware monitor to act as an intermediate between your UART and your storage (your array of integer signals). This hardware monitor will interpret commands coming from the UART and perform read/write operations in your storage. It will have one interface with the storage and another with the UART. You will have to define a kind of protocol with a syntax for your commands and of sequences of operations for each command.
Example: the monitor waits for commands coming from the UART. The first received character indicates whether it is a read (0) or a write (1). The four next characters are the target address, least significant byte first. If the command is a read, the monitor reads the data at the specified address in your storage and sends it to the UART, one byte at a time, least significant byte first. If the command is a write, the address is followed by a data to write in your storage at the specified address, least significant byte first, and your monitor waits until the data is received and writes it in your storage.
Optionally, the monitor could send an exit status byte at the end of each command to indicate potential errors (protocol errors, unmapped addresses, write attempts in read-only regions...)
Of course, depending on the characteristics of your application, you will probably define a completely different protocol, simpler or more complex, but the principle will be the same.
All this is usually implemented in software and runs on a CPU that has the UART as peripheral and the storage in its memory space. But if you do not have a CPU...
Warning: this is quite complex. The UART itself is quite complex. Not sure you should start with this if you are a VHDL beginner.
Your approach is not entirely wrong but you have a software orientated way of expressing this which indicate you are missing the fundamentals. People with strong software backgrounds tend to think in terms of the programming language and not in terms of the actual FPGA specific structures they want to achieve. It is the important to unlearn this if you want to be successful in designing for FPGA.
Based on what I just wrote you should consider in what type of FPGA structure you would like to store the data. The speed, resource and power requirements govern this choice. One suitable way to store the data would be in either a single or an array of either Block RAM or LUTRAM. Both of these structures can be inferred by using a signal of an array type in the hardware description language which is why I said you are not entirely off track. Consult the manual of your synthesis tool to find templates for how to infer these structures. An alternative is to use a vendor IP block or to instantiate a primitive directly but both those methods are clumsier in my opinion.
Important parameters to consider are the total number of words you need to store, the size of a word and the number of read/write operations per clock cycle. For higher number of reads per cycle an array of memories must be used since most FPGA memories only support two reads per cycle.

AT32UC3B0512 project compiled as AT32UC3B0256 -> Consequences

I just figured out that I have compiled and programmed my AT32UC3B0512 project using the AT32UC3B0256 as target device.
My application seams to work without problems. Is that possible? What are the differences between AT32UC3B0512 and AT32UC3B0256 (beside flash and ram size)?
in most cases the program EEPROM is the only difference.
You use lower target then you have
so it just limits the size of your program more then you can use in real.
The functionality is not affected at all (tested for quite some time on L0,A0,and A3 series).
The only thing you have to be careful with UC3 chips are the pin incompatibility between package and series
for example TQFP is much different then BGA ...
also the same package with different pin count is incompatible
also you can not change UC3A0 for UC3A3 ...
the last 2/3 digits are only the EEPROM size
and mostly does not affect SW/HW compatibility
[Note]
#SergioFormiggini is right the AT32UC3B0256 does not have DAC
it is the first time I see a difference in HW config of a chip with different memory size only on Atmel chips
Unless they also changed the memory map and or GPIO mappings you should be fine

major and minor numbers in device drivers

I read some material on major and minor numbers and have doubts in it.
What I understood:
driver has one major number associated with it due to register_chrdev_region().
mknod /dev/hello1 -c 123 32 will create device file with major number 123 and when application opens /dev/hello1 it searches driver with major number same as /dev/hello1.
multiple device file can be associated with one driver. and none of the two files in /dev will share same pair of major and minor number.
now some modern operating systems allows drivers with same major
numbers. Now in this case how mapping will work?
When you have multiple drivers associated with the same major number, you can differentiate between them through different minor number ranges under individual drivers. You can use the minor number as an index to a local array to access individual devices.
Also, it is advisable to use alloc_chrdev_region() to get the major number from the kernel dynamically rather than hardcoding a number that's currently free through register_chrdev_region().
Hope this helps!
When open() is called and the file entry contains a major/minor pair, open finds the device driver which has a corresponding struct device that contains the same major/minor pair. The major number alone is not enough to open a device.
Modern drivers should have their major number dynamically allocated by the kernel by leaving the dev_num set to zero when calling alloc_chrdev_region (&dev_num, 0, <number of contiguous minors to reserve>, DEVICE_NAME) If the call succeeds, MAJOR(dev_num) is the dynamically allocated major device number (and MINOR(dev_num) has the minor device number).

Xilinx ISE 9.2 and programming FPGA

Can anyone tell me how should I configure Xilinx ISE to get fastest FPGA programming speed ?
I have Spartan 3 Starter Board (FPGA chis is xc3s200). I'm not sure what's the name of programming cable, but I plug it in my computer to LPT1 (parallel port) and other side to JTAG header in the Spartan 3 board. Currently it takes over 1 minute to program it, and my project isn't that big (it's only beginner stuff).
Also, I've notices that now I need to turn on "Create ReadBack Data Files" and "Create Mask File" options. If they aren't checked, I can't program the FPGA.
Can anyone tell what are best Xilinx ISE options for FPGA programming ?
Thanks :)
P.S. I should tell you that I am running Xilinx ISE inside Windows XP virtual machine. Is maybe that what is causing the speed problem ? If it is, can you at least tell me how to get rid of that Mask file, because before I didn't create it and everything worked ...
The full-device bitstream (the "file" you load onto the FPGA) for every given device is always the same size; it does not depend on the functionality. An "empty" design's bitstream will be the same size as one that uses most of the FPGA's resources.
Configuration time depends on the configuration mode (serial, parallel 8/16/32 bits) and the configuration hardware (FPGA, PROM, Flash, programming cable capabilities, settings, and operating frequencies).
It sounds like you are using the very old parallel cable (PC-III?); try getting hold of the more recent USB ones and you should get faster programming times for JTAG (which is serial, btw).
1 minute is a looong time for a device that small.
Is that including a certain amount of compile time, or does impact take a long time to load on your system?
Anyway, speed improvements can come from:
Bitstream compression - you can turn this option on to produce a smaller bitstream, which loads faster
Faster configuration clock (change this in the configuration software, eg Impact) - no idea how fast the parallel cable will go, but I can do 12MHz with my USB cable on most boards I've tried and 6MHz on some of them which weren't quite so well-designed.
Try to see if bit-banging is possible. Haven't tried this myself but you might want to read this thread.
http://forums.xilinx.com/t5/Silicon-Devices-Others/FX2-Micrcontroller-JTAG-FPGA-configuration/td-p/41602
RRS

Resources