VLSI-EDA/PoC

IP Core Library - Published and maintained by the Chair for VLSI Design, Diagnostics and Architecture, Faculty of Computer Science, Technische Universität Dresden, Germany

Patrick Lehmann

@Paebbels

PoC FIFOs provide a fill-state in means of:

empty, half-full
empty, 1 quarters filled, 2 quarters filled, 3 quarters filled
...

If you set the fill/empty state bits to log2(FIFO_DEPTH), then you'll see the full FIFO fill-state and you can implement your allmost full signal based on that

Stjepan Henc

@sthenc

Ok, but I can't set it to full - 3 locations?

This may not be the best design, it is just what I am working with at the moment.

Patrick Lehmann

@Paebbels

Example: FIFO depth = 32, almost full at 28.
Internal counter has 5 bit, but only 3 bits are required to describe 28 out of 32, because it's equal to 7 out of 8

by checking if (fill_state = 7) you can figure out of the marking of 28 is reached

In your example, you would need to use 5 bits, because the gcd of (32 and 32-3) is 2^0 => you can't spare bits (fill_state_bits = 5 - 0)

Stjepan Henc

@sthenc

OK got it, sorry about that.

Patrick Lehmann

@Paebbels

Does it make sense?
Yes it's not the common Xilinx interface, but many protocols need a safety margin of e.g. 10% in the buffer, which can reduce the number of bits for comparison compared to a full fill-state check against all bits

Stjepan Henc

@sthenc

Yes, it takes some getting used to but it is a nice idea.

@Paebbels thank you very much, I think I will give this a try.

Patrick Lehmann

@Paebbels

OK. If you have problems in setting up PoC on your computer or compiling the files. Please ask again.

Oh and if you find errors in our setup documentation, please let us know :).

Stjepan Henc

@sthenc

I have a question that is probably off-topic, but I would be very thankful for any advice or pointers since this seems to be a non-trivial but fairly common problem.

My company is in the process of moving to git as our VCS, but in the process we would also like to figure out a smart way to version components shared between projects. We have several utility packages, IP's and behavioral models that have evolved into different variations. In itself this is not a big problem, but bug fixes and enhancements tend to not propagate upstream (if there is a single referent version at all), and we had instances of trying to reuse IP from several different projects, only to find that they use incompatible versions of utility packages. The legacy IP probably can't be recovered from the mess that was inflicted, but we are developing a new IP family, and I would really like to get it right (or at least better) this time.

Since you guys are probably using PoC with your projects and with in-house IP, I would like to know if there is a workflow you would recommend?

I looked at git submodules/subtree/subrepo, but the learning curve seems a bit too steep for my coworkers. and I am not sure if it is worth it.

I would appreciate any thoughts, and again, since this is off-topic I am open to discussing it somewhere else - or posting it somewhere else if there is a channel that deals with this type of stuff.

Patrick Lehmann

@Paebbels

PoC is intended to be used as a Git submodule.

There are the usecases for PoC (and this should apply to you usecase too): Documentation -> Using PoC

FranzForstmayr

@FranzForstmayr

Has anyone tried to package the PoC lib with vivado? It would be nice, just to write library PoC; use PoC.utils.allinstead of add the source files to vivado for every project.

Patrick Lehmann

@Paebbels

Hello @FranzForstmayr , there are plan to integrate PoC more closely into Vivado. I'm also thinking of creating packages for it. But honestly, the IPxact standard is a terribly standard... So PoC will only provide the capability to package PoC cores for Vivado, but it will never use the IPxact format internally.

The plan is to offer a project.ps1 --add-ip PoC.arith.prng command additionally to the poc.ps1 commands.

FranzForstmayr

@FranzForstmayr

Okay thank you. I don't like the whole IP neither, you have to create a new project in vivado every time, and it's pretty hard to track the files with git.

Patrick Lehmann

@Paebbels

Yes, it it slows down compilation...

Do you need the PoC IPs as an IP core in the block design or just a faster way to add the VHDL files of a core?

My first idea was to offer a command that adds missing files and the dependencies. So the script will scan you current project and add missing files based on the dependencies.

The other solution is to package PoC IPs and let Vivado find the files.

FranzForstmayr

@FranzForstmayr

I just want a fast way to add VHDL files or pachages to my hdl code. That would be possible of course, i just thought i wouldn't be the first one asking this question. But thank you anyway.

svenn71

@svenn71

Regarding IPxact, @Paebbels , have you seen https://github.com/kactus2/kactus2dev?

Patrick Lehmann

@Paebbels

@svenn71 I know Kactus. I do not support IPxact as a standard, because it's a XML nightmare. Don't get me wrong, I love XML, but IPxact has so many design faults ...

Mikkel Jeppesen

@Duckle29

Hey there, I'm trying to use PoC.misc.sync, but I can't seem to compile IP cores for it

================================================================================
                         The PoC-Library - Service Tool                         
================================================================================
Initializing PoC-Library Service Tool for synthesis
FATAL: An unknown or unhandled exception reached the topmost exception handler!
  Exception type:      AttributeError
  Exception message:   'Namespace' object has no attribute 'Dependencies'

Patrick Lehmann

@Paebbels

Hello @Duckle29. What IP core are you using from PoC.misc.sync?

Mikkel Jeppesen

@Duckle29

@Paebbels At the moment I'm just trying to figure out how to use it, I'm entirely a novice

but sync_bits_xilinx

@Paebbels Actually I may want sync_strobe or pulse, as it's a clk input varying from 0 to 600khz

though 600kHz doesn't sound that fast in terms of FPGAs

FranzForstmayr

@FranzForstmayr

Hi @Paebbels,
maybe it's a dumb question, but have you aver thought about splitting up the PoC Library into two parts, a top level wrapper with python scripts and a hdl only library as a submodule? These two projects could be developed independently, and it would be easier to include the hdl library as a submodule in other projects.

Patrick Lehmann

@Paebbels

Hello @FranzForstmayr,
with PoC v1.2.0 (and 1.2.0-Vivado) - 8 days ago, PoC was split into:

"VHDL code" + pyIPCMI description files (in .pyIPCMI), and
the submodule pyIPCMI in lib/pyIPCMI.

Patrick Lehmann

@Paebbels

Currently, I have a new student working on:

a generic 10G/40G/100G Ethernet MAC (xgemac)
a generic 1/10/40/100G capable IP and UDP layer
adapters from 1/10/40/100G to 1G lowspeed protocols like
- ARP
- NDP
- ICMP

Patrick Lehmann

@Paebbels

If you like, please checkout the latest version and have a try if I made the split correct :). I'm currently checking if everything works as expected.

I also have received a list of improvements, which I'm currently reviewing. But I thought the split was more important and may need some further fixes which I can deliver with the reviewed data.

FranzForstmayr

@FranzForstmayr

ok, i have to look exactly at this changes. For some reason GitHub hides the 1.2 release at first sight. Is the PoC hdl part tightly coupled with your build scripts? Or could you imagine to create another abstraction layer between?

Patrick Lehmann

@Paebbels

The HDL part is not so tighly coupled. The file formats for the IP core database and descriptions might be the problematic part. Currently these formats are stable but might change in a newer release. Currently, I have planned a better parser but no new formats.

FranzForstmayr

@FranzForstmayr

Ok, i'm using a VUnit top wrapper and want to use the PoC library as a submodule. Maybe i can find a good way to include the PoC Library and automatically include vhdl files depending on their version (v08 and v93 issues).

Maybe there's also a nice way to replace PoC/src/common/my_project.vhdl files, because the file path is always specific for a given project. Same for my_config.vhdl when writing a generic module.

Patrick Lehmann

@Paebbels

PoC has 3 use cases, have you reviewed them on ReadTheDocs?

stand alone - zip
stand alone - Git
Git submodule

You should use the latter use case. Here you create one my_config.vhdl per project. It is shared in the parent repository.

The my_project.vhdl is specific to each machine and not intended to be shared with Git.

If you don't use write file and read file operations in synthesis, you can use dummy data in my_project.vhdl

FranzForstmayr

@FranzForstmayr

yeah, this is the part, where i want to use the VUnit Framework, it's easy to read and write files and verify them in python after simulation

I'll double check the remaining issue, my last hdl project is already some month ago.

Patrick Lehmann

@Paebbels

There is a branch on my machine, where I investigate how to integrate VUnit (to be specific: the VUnit runner) into PoC

Where communities thrive

People

Repo info

Activity