Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out what the contents of gateware/encoder/vhdl/header.hex is #297

Open
mithro opened this issue Aug 10, 2016 · 7 comments
Open

Figure out what the contents of gateware/encoder/vhdl/header.hex is #297

mithro opened this issue Aug 10, 2016 · 7 comments

Comments

@mithro
Copy link
Member

mithro commented Aug 10, 2016

What is this file? How was it made? etc....

@akhil-123
Copy link

akhil-123 commented Feb 15, 2018

'gateware/encoder/vhdl/header.hex' specifies the initial content of a memory block rambyte in the file (https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/encoder/vhdl/JFIFGen.vhd) , that is, the initial values for each address. One can see the initializing of memory block in -
https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/encoder/vhdl/JFIFGen.vhd
Where "initial $readmemh("header.hex", mem) " initializes the memory. Now this memory is assigned to q and ram_bytes in the JFIFGen.vhd(https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/encoder/vhdl/JFIFGen.vhd) is assigned to q.
So basically header.hex is basically initializing the the memory.
Process for creating hex file is as follows:
We compile Verilog to RTL netlists, then synthesize Verilog to EDIF, then place and route EDIF to produce HEX files that can be loaded into an FPGA.
So this hex file might be created in the same way.

GitHub
HDMI2USB-litex-firmware - A version of the HDMI2USB firmware based around LiteX tools produced by @enjoy-digital (based on misoc+migen created by @m-labs)
GitHub
HDMI2USB-litex-firmware - A version of the HDMI2USB firmware based around LiteX tools produced by @enjoy-digital (based on misoc+migen created by @m-labs)
@mithro
Copy link
Member Author

mithro commented Feb 15, 2018

@akhil-123 Yes, we understand what readmemh() does in Verilog. What we don't understand is the contents of this file. See the title of this bug.

I think this is probably something like a JPEG header or something?

@akhil-123
Copy link

akhil-123 commented Feb 16, 2018

This header.hex file is a JPEG/JFIF file (minimal file format which enables JPEG bitstreams to be exchanged between a wide variety of platforms and applications) in which the contents are as follows:

  1. At the starting of file we can see the values FF and D8 which is the start of image marker(SOI).
  2. After that in the 3rd and 4th line FF and E0 are written indicating a JFIF App0 application marker.
  3. The next two bytes 00 and 10 tell us the APP0 sgement length followed by the five byte values 4Ah 46h 49h 46h 00h (JFIF).(If these values are found, the SOI marker (FFh D8h) marks the beginning of a JFIF data stream).
  4. The next two bytes 01 01 indicate the version of JFIF specification.
  5. Next three bytes indicate Units, Xdensity and Ydensity( unit of measurement used to describe the image resolution). Since Unit field is 00 it indicates that take the measurement as pixel aspect ratio = Ydensity:Xdensity. Xdensity and Ydensity are the horizontal and vertical resolution of the image data, respectively. Unit field is followed by two bytes of Xdensity and 2 bytes of Y density.
  6. Now line 19 and 20 indicate Xthumbnail (Horizontal pixel count of the following embedded RGB thumbnail) and Ythumbnail (Vertical pixel count of the following embedded RGB thumbnail).
  7. Lines 21 and 22 have values FF and C0 indicating the start of frame (Indicates that this is a baseline DCT-based JPEG, and specifies the width, height, number of components, and component subsampling ).
    Now in the whole file wherever we found the values mentioned below they indicate following things
  • FF , C4 together one after another defines a huffman table.( lines - (178 and 179) , (211 and 212), (244 and 245), (427 and 428) ,
  • FF , DB together one after another defines a quantization Table.(lines - (40 and 41) , (109 and 110) ,
  • FF , DA together one after another defines the start of scan.( Begins a top-to-bottom scan of the image)(lines 610 and 611)

But In the header.hex file i could not find the EOI (end of image) marker which is FF D9. I think it should be present in the file.

@mithro
Copy link
Member Author

mithro commented Feb 16, 2018

@akhil-123 Would you be interested in writing up a small Python program which uses the either struct module or struct support in the ctypes module (probably combined with the hexfile module) to read/write this data?

@akhil-123
Copy link

Yeah, I will try my best to finish it as soon as possible.

@mithro
Copy link
Member Author

mithro commented Feb 17, 2018

@akhil-123 No hurry!

FYI You should come and join us in our IRC chat room [irc://irc.freenode.net/#timvideos] if you haven't already! A web based client is available here.

@akhil-123
Copy link

can u increase the description on what these read and write operations should do ?

mithro added a commit that referenced this issue Jan 30, 2020
 * litex changed from v0.1-1335-gbb64f8a7 to v0.1-1338-g85d66072
    * 85d66072 - cpu/minverva: give more explicit error message when not able to elaborate cpu <Florent Kermarrec>
    * 3465fc96 - Merge pull request #297 from mithro/mem-region-pp <Tim Ansell>
    * 4408dad9 - Improve the error message on memory region conflict. <Tim 'mithro' Ansell>

Full submodule status
--
 3a6108a75be356a3dc53760d22782f1323248b6b edid-decode (remotes/origin/HEAD)
 01d8f819f15baf9a8cc5d96945a51e4d267ff564 flash_proxies (remotes/origin/HEAD)
 08325dd04e65859d3410e730dde7ab81d338d6c3 litedram (remotes/origin/HEAD)
 4d9e74f10a3fe7bf71ba9bde50f49689c6458dc5 liteeth (remotes/origin/HEAD)
 47e76f447f6e3d97aac2638a98f967d44db5c349 litepcie (remotes/origin/HEAD)
 db5d2f7881161ce5b9a10a0ab42555f884b9d7c1 litesata (remotes/origin/HEAD)
 7a9fa9d3b18362bf707dff25a78661395ef9ee7a litescope (remotes/origin/HEAD)
 7457a29b1a47fe15e81fa37f3bbdd510788f1d53 liteusb (remotes/origin/HEAD)
 49bafa481075e0bfbaf067b63c351ec29e993894 litevideo (remotes/origin/HEAD)
 85d6607257650a9b1824a2d2d7931324f7e52388 litex (v0.1-1338-g85d66072)
 742360f2ba4c400c6164908f03c6ca3d965f168b litex-renode (remotes/origin/HEAD)
 41922fde2a8c36cd0f99d4b7ebb3ba9c37ce1489 migen (0.6.dev-306-g41922fd)
 4d6ad28f5966f1f7c94a8f83ef50f07d7e62123c nmigen (v0.1rc1-12-g4d6ad28)
mithro added a commit that referenced this issue Jan 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment