Month: January 2018

Upgrading Fedora

I have an old T61 notebook with Fedora 23. Since this distribution release is quite outdated I upgraded to the latest release version (27) this weekend. This can be done quite easily with the dnf-plugin-system-upgrade package.

$ sudo dnf install dnf-plugin-system-upgrade

$ sudo dnf system-upgrade download –refresh –releasever=27

$ sudo dnf system-upgrade reboot

If all goes well Fedora will upgrade to release 27 after the next reboot. I had to uninstall a few packages first, for which dnf complained about dependency conflicts.

For more details check out the Fedora Wiki.

ASIC Design Tutorials And Why They’re Rare

Most information about ASIC technologies and semiconductor processes are not public and only supplied under strict NDAs. Therefor only very few useful tutorials about ASIC design and layout exist. Though few in number they do exist. Here are a few noteworthy ones. I did not read through them completely but only briefly skipped through them and thought they looked promising at first glance.

http://www.designinganalogchips.com/
https://www.mics.ece.vt.edu/ICDesign/Tutorials/Overview/index.html
https://web.archive.org/web/*/Designing%20Analog%20Chips

Simulation Advice II

Here is some more general advice for simulation of HDL code. No respect is paid to verification methodologies like UVM or OSVVM. Most of it is obvious, but it helps my memory when I write these things down.

  • Use one big record type to define what is part of a test case.
    Then define multiple constants of the test case record type, one for each test case.
    Scheduling of and switching between test cases becomes a matter of a single signal/variable assignment.
  • Read test cases from a file. Switching between test cases becomes a matter of reading from an different file. Test cases can be run in sequence by reading several files in sequence. It’s now possible to add test cases into a version control system separately. A disadvantage is that additional coding and maintenance for the test case files is required.
  • Write reusable procedures and functions to generate the stimuli for the DUT. This is a kind of primitive BFM.

Simulation Advice

Here is some general advice for simulation of HDL code. No respect is paid to verification methodologies like UVM or OSVVM. Most of it is obvious, but it helps my memory when I write these things down.

  • Use assert statements to catch error events. Your eyes can miss even the most obvious error when scanning over some simulation waveforms after a long day in front of the screen.
  • Use log files and/or report statements to save information about the status and progress of simulation, errors or any other noteworthy event. This will speed up the task of locating events of interest and will allow you to do text searches over those files.
  • Use colors, the right radix for numbers and hierarchical structure in your waveform viewer for optimal data representation. Unless you prefer to look at heaps of green lines with loads of 0’s and 1’s around them.
  • Save your simulator/waveform settings. At some point you will come back and won’t have to repeat the tedious task of setting up a neat waveform view. The simulator/waveform settings should also go into the repository (separate folder for each simulator), but it’s a matter of taste.

Ternary operator for VHDL

On occasion it can be super useful to have the ternary operator ? : at hand. Many programming languages like C have it and – without proof – I dare claim that it is much appreciated by many coders out there.

Powered by WordPress & Theme by Anders Norén

Close Bitnami banner
Bitnami