by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 14 14:56
    mbieker opened #67
  • Aug 26 02:39
  • Aug 18 07:56
  • Aug 16 17:08

    mzabeltud on v1.1.2-Vivado

    Added mig_ZTEX204_XC6SLX16_DDR. Fixed mig_ZTEX204_XC6SLX16_DDR. Removed unused logic in mem.tim… and 1 more (compare)

  • Aug 16 16:22

    mzabeltud on v1.1.2

    Removed unused logic in mem.tim… (compare)

  • Aug 16 14:34

    mzabeltud on v1.1.2

    Fixed mig_ZTEX204_XC6SLX16_DDR. (compare)

  • Aug 16 14:17

    mzabeltud on v1.1.2

    Added mig_ZTEX204_XC6SLX16_DDR. (compare)

  • Aug 14 19:51

    mzabeltud on v1.1.2-Vivado

    Added board QM_XC6SLX16_DDR3 Added MIG DDR3 controller for Q… Added board QM_XC6SLX16_SDRAM and 11 more (compare)

  • Aug 13 04:08
  • Aug 12 19:46

    mzabeltud on v1.1.2

    Added entity PoC.mem_timeslice_… (compare)

  • Aug 11 19:47

    mzabeltud on v1.1.2

    Fixed timings for SDRAM Control… (compare)

  • Aug 07 21:52
  • Jul 19 13:39
  • Jul 16 02:25
  • Jun 20 18:27
    Divyanirankari edited #66
  • Jun 20 18:26
    Divyanirankari edited #66
  • Jun 20 18:25
    Divyanirankari opened #66
  • Jun 17 19:58
    Peppar commented #62
  • May 15 18:41
  • May 11 11:52
    oholimoli commented #62
kraigher
@kraigher
Regardless of what method you have choosen to implement for detecting Python it can still be done by a Python-scipt as well
Patrick Lehmann
@Paebbels
I personally don't support Python 2 in general :)
kraigher
@kraigher
Ok, in VUnit we have actively tried to use the least common denominator since a lot of corporations are stuck on old versions, but it is definately an extra maintainance burden
Patrick Lehmann
@Paebbels
As we decided to use Python 3.4 and later 3.5, I found out that many packages have backports on PyPI, so we could provide workarounds to load these modules from PyPI if not included in Python itself.

an extra maintainance burden

Yes
But also on the other end of version numbers ... I'll always be the first to find bugs :)

My original question was about argcomplete ... are you using autoprogram in Sphinx?
kraigher
@kraigher
no we use sphinx-argparse to generate documentation of CLI
is autoprogram better?
Patrick Lehmann
@Paebbels
I needed to write a sphinx specific frontend for that: https://github.com/VLSI-EDA/PoC/blob/master/docs/PoCSphinx.py?ts=2#L40
let me look if I wrote the correct name ...

my conf.py says:

# local extensions (patched)
    'autoprogram',                 #'sphinxcontrib.autoprogram',

Source https://github.com/VLSI-EDA/PoC/blob/master/docs/conf.py?ts=2

My version adds labels after each sub-parser entry so you can better reference the commands
Patrick Lehmann
@Paebbels
I'm happy with the results :)
I'm also using decorators to attache parameters to a handler method: https://github.com/VLSI-EDA/PoC/blob/master/py/PoC.py?ts=2#L878
It's like using .... how is it called ... "click 5"?
Patrick Lehmann
@Paebbels
Please subscribe also to our VLSI-EDA/News Gitter news room to received the latest news about PoC.
Subscribe to VLSI-EDA/News
Stjepan Henc
@sthenc

Hello,

I am looking at the PoC library FIFOs https://github.com/VLSI-EDA/PoC/tree/master/src/fifo .

I have a few questions:

What happened to https://github.com/VLSI-EDA/PoC/blob/master/src/fifo/fifo_dc_got.vhdl

Patrick Lehmann
@Paebbels
Hello @sthenc
Hmmm that's a good question
Stjepan Henc
@sthenc
It is still listed in the src/fifo/readme but is not in the repo
Patrick Lehmann
@Paebbels
I have to check that case.
The FIFO was not replaced and is part of PoC. We have an internal version of PoC and a script to control which files are released. Maybe there is an error in that script / configuration, which misses to copy the dc FIFO to the public GitHub repository. (That currently my best guessing.)
Meanwhile you can use the ic FIFO and replace it later with the dc FIFO.
Stjepan Henc
@sthenc

OK thank you for the info.

Also, I am having some trouble with my company's in-house dual-clock fifo behaving strangely for the unrelated clock use case.

I had the idea of maybe using the IC FIFO, but it doesn't have the classic almost_full/almost_empty flags.

Do you have any ideas where I could find some other commercial-friendly OSS dual clock FIFO implementations?

Patrick Lehmann
@Paebbels
Do you really need the almost full signal or just a fill-state indication?
Stjepan Henc
@sthenc
Fill state is also ok, I just need to know in advance when to prepare to stop reading.
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.