Thread: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Angel E. <ang...@gm...> - 2012-09-28 07:27:08
|
Hi,
For the past couple of years I've been following the MyHDL project
with a lot of interest. I've been subscribed to the mailing list and
followed many of the interesting discussions in here. I've done a few
of the examples on my spare time and I have read the documentation a
couple of times.
I really like the language. I find it very clear and simply way nicer
than VHDL, which is what we use in our projects where I work. I have
quite a lot of experience with Python, and at work I sometimes use it
with some of its great scientific packages, such as simpy, scipy,
matplotlib, etc, mainly for simulation purposes although most of my
colleagues use Matlab for this.
That being said, I have trouble coming up with a good way to integrate
MyHDL into our existing workflows. I'm looking for advice here to see
if there is a way that we could use MyHDL to improve our productivity.
Our current setup is as follows:
- We use Xilinx FPGAs (Spartan and Virtex 5 and 6 and probably Kintex
or Virtex 7 soon).
- Our firmware code is 100% VHDL.
- We use the latest version of the Xilinx ISE environment (which
unfortunately is pretty weak, specially in the editing and code
exploration departments).
- Some of us are also using the excellent Sigasi editor (which I
discovered thanks to this list). For now we are using the basic
edition which is nice but we hope to be able to buy a few licenses
soon.
- We use some Xilinx IP cores, which come as an NGC plus a VHDL simulation file.
- We receive a basic firmware "shell" from our hardware team, which,
basically, is the top VHDL file of the design. This "shell" sets up
the system clocks, instantiates the different devices that are used to
connect the FPGA firmware to the outside world (i.e. the different
ports, etc), as well as the memories, and other devices that are
present on the FPGA and on its board.
- That "shell" also contains an instance of the actual "top
entity" that is the one that we create.
- They also give us the basic "constraints file" which selects the
pinout, etc.
- We have no control over what we receive from the HW team. We
must use what they give us "as is".
- We do not use any custom TCL scripts to build our firmware. We just
use the ISE "Generate Programming File" command.
- We use either Modelsim or the builtin ISE ISim simulator to run our
simulations. We are exploring the possibility of using Xilinx' new
Vivado Simulator as well.
- We usually create a "high level" Matlab or python based simulation
models of our system. The model is not necessarily bit accurate to the
actual VHDL implementation, but we try to make it so that it is able
to generate the inputs necessary to drive our VHDL test benches
(including configuration and data), and even our compiled firmware
(mostly configuration)
- We create VHDL test benches for most (although sadly not all) of our
modules. These test benches are usually quite simple. They just read
the inputs from some files (generated with our Matlab or python
simulators) and save the outputs so that they can be compared to some
"golden" outputs (usually generated with our high level simulators).
- When there are issues we often use the test benches to simulate
the models and we use the (not so good) visualization capabilities of
Modelsim to debug.
- We also tend to use ChipScope to add "logic analyzer modules" to
our firmware so that we can debug "live" some specially tricky issues.
- We also use a logic analyzer port to output data that is then
captured by an external logic analizer. This is necessary when the
amount of data to capture is so great that it would not fit on a
ChipScope block.
What we definitely cannot do is introduce huge changes to our
development practices. I am sure that there are plenty of things that
we could do differently and that we should (and probably will)
improve. However I'd like to introduce this new technology gradually,
and once people are more comfortable with it we could do bigger
changes to our work flow.
The way I see it there are a few barriers that make it hard for us to
use MyHDL. It is likely that some of these are moot (i.e. perhaps when
we start using MyHDL I'll realize that they are not important), but
for now they seem things that we should deal with:
1. The MyHDL code may need to interface with existing blocks,
particularly with IP cores. This results in several problems:
- It would make it hard to run simulations on the "MyHDL world"
since we do not have MyHDL models for the Xilinx IP cores.
- I got the impression that the MyHDL to VHDL "interface" is not
that clean and that the process is manual (I have not looked much into
this, so I may be wrong).
2. We should come up with a way to automatically generate the VHDL
from the MyHDL when we generate our programming file.
3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim
(at least on Windows).
4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH
and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD
(and rightly so). There may be issues mixing both sets of libraries.
5. There is no editor integration (not even with Sigasi).
6. I believe that the fact that the VHDL code that MyHDL generates is
"flat" is a problem, because it makes it harder to introduce MyHDL
little by little.
- This may be just my perception and turn out to be a non issue,
but I think that if MyHDL generated regular structured code (e.g. if
you could tell MyHDL "place all these processes on a single entity
named foo") it would be much easier to start using MyHDL to create
smaller modules that could be added to our regular VHDL project "as
is".
There are probably other issues that I have not thought about, and
maybe some of these are not a problem at all.
I'd like to get your opinions and your advice on whether you think it
makes sense to try to fit MyHDL into our workflow. Perhaps it does not
make sense unless you use MyHDL from start to end, but I hope it is
possible.
Cheers,
Angel
|
|
From: Christopher F. <chr...@gm...> - 2012-09-28 12:08:21
|
On 9/28/2012 2:26 AM, Angel Ezquerra wrote: > Hi, > > For the past couple of years I've been following the MyHDL project > with a lot of interest. I've been subscribed to the mailing list and > followed many of the interesting discussions in here. I've done a few > of the examples on my spare time and I have read the documentation a > couple of times. > > I really like the language. I find it very clear and simply way nicer > than VHDL, which is what we use in our projects where I work. I have > quite a lot of experience with Python, and at work I sometimes use it > with some of its great scientific packages, such as simpy, scipy, > matplotlib, etc, mainly for simulation purposes although most of my > colleagues use Matlab for this. > Do you mean "simpy" or sympy? One is a CAS and one is a discrete event simulator using generators and decorators (hmm, sounds familiar). .chris |
|
From: Angel E. <ang...@gm...> - 2012-09-28 12:22:59
|
On Fri, Sep 28, 2012 at 2:07 PM, Christopher Felton <chr...@gm...> wrote: > On 9/28/2012 2:26 AM, Angel Ezquerra wrote: >> Hi, >> >> For the past couple of years I've been following the MyHDL project >> with a lot of interest. I've been subscribed to the mailing list and >> followed many of the interesting discussions in here. I've done a few >> of the examples on my spare time and I have read the documentation a >> couple of times. >> >> I really like the language. I find it very clear and simply way nicer >> than VHDL, which is what we use in our projects where I work. I have >> quite a lot of experience with Python, and at work I sometimes use it >> with some of its great scientific packages, such as simpy, scipy, >> matplotlib, etc, mainly for simulation purposes although most of my >> colleagues use Matlab for this. >> > > Do you mean "simpy" or sympy? One is a CAS and one is > a discrete event simulator using generators and decorators > (hmm, sounds familiar). > > .chris > I misspelled it. I meant sympy (http://sympy.org/en/index.html)! Angel |
|
From: Christopher F. <chr...@gm...> - 2012-09-28 12:16:26
|
On 9/28/2012 2:26 AM, Angel Ezquerra wrote: > Hi, > > For the past couple of years I've been following the MyHDL project > with a lot of interest. I've been subscribed to the mailing list and > followed many of the interesting discussions in here. I've done a few > of the examples on my spare time and I have read the documentation a > couple of times. > > I really like the language. I find it very clear and simply way nicer > than VHDL, which is what we use in our projects where I work. I have > quite a lot of experience with Python, and at work I sometimes use it > with some of its great scientific packages, such as simpy, scipy, > matplotlib, etc, mainly for simulation purposes although most of my > colleagues use Matlab for this. > > That being said, I have trouble coming up with a good way to integrate > MyHDL into our existing workflows. I'm looking for advice here to see > if there is a way that we could use MyHDL to improve our productivity. > <snip> My quick two cents is that you adopt the "IP" developed with MyHDL approach. You start using the tool this way. Your co-workers might never know you are using MyHDL. As you indicate, there are some short comings to this approach. One of the items you suggested is using MyHDL for top-level simulation/verification (cosimulation with VHDL). What VHDL simulator are you using? Since you have an established flow, I imagine it will be hard to radically change. You will need to methodically work MyHDL in. My best guess, this would mean developing individual pieces with MyHDL then incorporating into the system. Then second, you could start building your system sim and verification in MyHDL. This will require VHDL cosim. There might be enough interest to spend some cycles getting VHDL cosim working, the hold back has been access to commerical simulators. Regards, Chris |
|
From: Angel E. <ang...@gm...> - 2012-09-28 12:31:48
|
On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton <chr...@gm...> wrote: > On 9/28/2012 2:26 AM, Angel Ezquerra wrote: >> Hi, >> >> For the past couple of years I've been following the MyHDL project >> with a lot of interest. I've been subscribed to the mailing list and >> followed many of the interesting discussions in here. I've done a few >> of the examples on my spare time and I have read the documentation a >> couple of times. >> >> I really like the language. I find it very clear and simply way nicer >> than VHDL, which is what we use in our projects where I work. I have >> quite a lot of experience with Python, and at work I sometimes use it >> with some of its great scientific packages, such as simpy, scipy, >> matplotlib, etc, mainly for simulation purposes although most of my >> colleagues use Matlab for this. >> >> That being said, I have trouble coming up with a good way to integrate >> MyHDL into our existing workflows. I'm looking for advice here to see >> if there is a way that we could use MyHDL to improve our productivity. >> > <snip> > > My quick two cents is that you adopt the "IP" developed > with MyHDL approach. You start using the tool this way. > Your co-workers might never know you are using MyHDL. I'm not sure I understand what you mean. Do you mean that I would write my code on MyHDL, generate the VHDL and publish the generated VHDL as an "IP"? If that is the case I fear that the fact that the automatically generated code is flat may be a problem. Depending on how big are the modules that I work on it the resulting VHDL could be pretty big, couldn't it? I guess my colleagues would find that odd :-P > As you indicate, there are some short comings to this > approach. One of the items you suggested is using MyHDL > for top-level simulation/verification (cosimulation with > VHDL). What VHDL simulator are you using? We currently use Modelsim and ISim, on Windows. > Since you have an established flow, I imagine it will be > hard to radically change. You will need to methodically > work MyHDL in. My best guess, this would mean developing > individual pieces with MyHDL then incorporating into the > system. That is what I'd like to do but I don't quite see a good way to do so, given the concerns that I stated on my first email. > Then second, you could start building your system sim and > verification in MyHDL. This will require VHDL cosim. There > might be enough interest to spend some cycles getting VHDL > cosim working, the hold back has been access to commerical > simulators. Being able to write test benches in python would be awesome, that is for sure! I really dislike how limited is VHDL for IO and other non synthesizable stuff. Angel |
|
From: Christopher F. <chr...@gm...> - 2012-09-28 13:12:25
|
On 9/28/2012 7:31 AM, Angel Ezquerra wrote: > On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton > <chr...@gm...> wrote: >> On 9/28/2012 2:26 AM, Angel Ezquerra wrote: >>> Hi, >>> >>> For the past couple of years I've been following the MyHDL project >>> with a lot of interest. I've been subscribed to the mailing list and >>> followed many of the interesting discussions in here. I've done a few >>> of the examples on my spare time and I have read the documentation a >>> couple of times. >>> >>> I really like the language. I find it very clear and simply way nicer >>> than VHDL, which is what we use in our projects where I work. I have >>> quite a lot of experience with Python, and at work I sometimes use it >>> with some of its great scientific packages, such as simpy, scipy, >>> matplotlib, etc, mainly for simulation purposes although most of my >>> colleagues use Matlab for this. >>> >>> That being said, I have trouble coming up with a good way to integrate >>> MyHDL into our existing workflows. I'm looking for advice here to see >>> if there is a way that we could use MyHDL to improve our productivity. >>> >> <snip> >> >> My quick two cents is that you adopt the "IP" developed >> with MyHDL approach. You start using the tool this way. >> Your co-workers might never know you are using MyHDL. > > I'm not sure I understand what you mean. Do you mean that I would > write my code on MyHDL, generate the VHDL and publish the generated > VHDL as an "IP"? Essentially, but I don't mean that you have to create a netlist and integrate. Simply take the generated VHDL and use in the design. > > If that is the case I fear that the fact that the automatically > generated code is flat may be a problem. Depending on how big are the > modules that I work on it the resulting VHDL could be pretty big, > couldn't it? I guess my colleagues would find that odd :-P Why would a large VHDL be an issue? I don't think it is. If you really need the hierarchy there are options, just takes a little more work. > >> As you indicate, there are some short comings to this >> approach. One of the items you suggested is using MyHDL >> for top-level simulation/verification (cosimulation with >> VHDL). What VHDL simulator are you using? > > We currently use Modelsim and ISim, on Windows. Isim doesn't support PLI/VPI/DPI/VHPI you won't be able to do cosim with Isim. There's other interest with mti VHDL cosim, this has a decent change of being developed. If that occurs, you can start developing a top-level verification environment and blow the socks off your co-workers! They will be utterly amazed. > >> Since you have an established flow, I imagine it will be >> hard to radically change. You will need to methodically >> work MyHDL in. My best guess, this would mean developing >> individual pieces with MyHDL then incorporating into the >> system. > > That is what I'd like to do but I don't quite see a good way to do so, > given the concerns that I stated on my first email. I believe all the concerns are manageable. I guess nothing really stood out that needed to be addressed. Let me look at the bullet list again. > >> Then second, you could start building your system sim and >> verification in MyHDL. This will require VHDL cosim. There >> might be enough interest to spend some cycles getting VHDL >> cosim working, the hold back has been access to commerical >> simulators. > > Being able to write test benches in python would be awesome, that is > for sure! I really dislike how limited is VHDL for IO and other non > synthesizable stuff. > > Angel |
|
From: Christopher F. <chr...@gm...> - 2012-09-28 13:23:44
|
<snip>
> The way I see it there are a few barriers that make it hard for us to
> use MyHDL. It is likely that some of these are moot (i.e. perhaps when
> we start using MyHDL I'll realize that they are not important), but
> for now they seem things that we should deal with:
>
> 1. The MyHDL code may need to interface with existing blocks,
> particularly with IP cores. This results in several problems:
> - It would make it hard to run simulations on the "MyHDL world"
> since we do not have MyHDL models for the Xilinx IP cores.
> - I got the impression that the MyHDL to VHDL "interface" is not
> that clean and that the process is manual (I have not looked much into
> this, so I may be wrong).
You would still use the VHDL environment interfacing
to IP cores for simulation would be the same. In your
MyHDL "IP" development you would need to generate a
model (you can stub it out) or cosim.
> 2. We should come up with a way to automatically generate the VHDL
> from the MyHDL when we generate our programming file.
Yes, you can create a python script that drives
everything (Python world domination).
> 3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim
> (at least on Windows).
Not possible with iSim, possible with Modelsim but it will
take some work. There is other cosim VHDL interest.
> 4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH
> and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD
> (and rightly so). There may be issues mixing both sets of libraries.
I don't believe this is an issue, because VHDL is
strongly typed you have to do explicit conversion going
from one type to another. It can be a pain but shouldn't
be a problem. I have had this issue in the past where
all my VHDL used numeric_std and I had to add type
conversion at the interfaces to the legacy HDL.
> 5. There is no editor integration (not even with Sigasi).
?? What do you mean by editor integration. MyHDL is
simply Python, pydev in Eclipse works with other Eclipse
packages.
> 6. I believe that the fact that the VHDL code that MyHDL generates is
> "flat" is a problem, because it makes it harder to introduce MyHDL
> little by little.
> - This may be just my perception and turn out to be a non issue,
> but I think that if MyHDL generated regular structured code (e.g. if
> you could tell MyHDL "place all these processes on a single entity
> named foo") it would be much easier to start using MyHDL to create
> smaller modules that could be added to our regular VHDL project "as
> is".
I don't see this as an issue? If you have an existing
HDL design, say the top level looks like this (pseudo code,
err myhdl).
i1 = block_vhdl(...)
i2 = block_vhdl(...)
i3 = block_myhdl_vhdl(...)
The "i3" module is the "flat" myhdl converted to VHDL.
There are some limitations but not many and most are
manageable. I don't think this should be a concern.
>
> There are probably other issues that I have not thought about, and
> maybe some of these are not a problem at all.
>
> I'd like to get your opinions and your advice on whether you think it
> makes sense to try to fit MyHDL into our workflow. Perhaps it does not
> make sense unless you use MyHDL from start to end, but I hope it is
> possible.
>
> Cheers,
>
> Angel
>
|
|
From: Angel E. <ang...@gm...> - 2012-10-04 21:11:27
|
Hi again Chris, more replies to some of your advice below. On Fri, Sep 28, 2012 at 3:23 PM, Christopher Felton <chr...@gm...> wrote: > <snip> >> The way I see it there are a few barriers that make it hard for us to >> use MyHDL. It is likely that some of these are moot (i.e. perhaps when >> we start using MyHDL I'll realize that they are not important), but >> for now they seem things that we should deal with: >> >> 1. The MyHDL code may need to interface with existing blocks, >> particularly with IP cores. This results in several problems: >> - It would make it hard to run simulations on the "MyHDL world" >> since we do not have MyHDL models for the Xilinx IP cores. >> - I got the impression that the MyHDL to VHDL "interface" is not >> that clean and that the process is manual (I have not looked much into >> this, so I may be wrong). > > You would still use the VHDL environment interfacing > to IP cores for simulation would be the same. In your > MyHDL "IP" development you would need to generate a > model (you can stub it out) or cosim. Some of the IP cores that we use are quite complex (e.g. turbo-decoders). We could stub them out as you suggest but it makes using MyHDL a little less convenient. Also, most Xilinx' cores use std_logic_vector for their interfaces. Would that be a problem? How do you convert the native MyHDL intbv types into the std_logic_vector required by the external IP cores? BTW, it would be super-nice if you could somehow import a regular VHDL file into MyHDL (e.g. calling some MyHDL function with the VHDL filename) and that made MyHDL automatically aware of the corresponding entity (i.e. its name, interface, etc). I don't know how realistic is that though :-) >> 2. We should come up with a way to automatically generate the VHDL >> from the MyHDL when we generate our programming file. > > Yes, you can create a python script that drives > everything (Python world domination). Probably not hard but it complicates things further compared to our existing workflow. Hence my "concern". >> 3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim >> (at least on Windows). > > Not possible with iSim, possible with Modelsim but it will > take some work. There is other cosim VHDL interest. Recently I've started playing with the Vivado Simulator, which is Xilinx' next generation simulator (which replaces ISim). I wonder if it supports PLI/VPI/DPI/VHPI. >> 4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH >> and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD >> (and rightly so). There may be issues mixing both sets of libraries. > > I don't believe this is an issue, because VHDL is > strongly typed you have to do explicit conversion going > from one type to another. It can be a pain but shouldn't > be a problem. I have had this issue in the past where > all my VHDL used numeric_std and I had to add type > conversion at the interfaces to the legacy HDL. Did this happen when you were using MyHDL to drive some legacy HDL code? Do you have some examples available? >> 5. There is no editor integration (not even with Sigasi). > > ?? What do you mean by editor integration. MyHDL is > simply Python, pydev in Eclipse works with other Eclipse > packages. What I mean is that you do not get to have a mixed MyHDL / VHDL "project" where you can see all your modules on a hierarchy view (as you can on ISE or Sigasi) and where you can double click on the module to open the corresponding MyHDL file. This exists for plain VHDL and is quite nice. I wonder if Jan can somehow convince the Sigasi guys to add MyHDL support to their awesome editor... :-) This is by no means a huge thing, but I having an integrated development environment would be nice. Not having it is a (small) step backwards compared to an all VHDL or all Verilog environment. >> 6. I believe that the fact that the VHDL code that MyHDL generates is >> "flat" is a problem, because it makes it harder to introduce MyHDL >> little by little. >> - This may be just my perception and turn out to be a non issue, >> but I think that if MyHDL generated regular structured code (e.g. if >> you could tell MyHDL "place all these processes on a single entity >> named foo") it would be much easier to start using MyHDL to create >> smaller modules that could be added to our regular VHDL project "as >> is". > > I don't see this as an issue? If you have an existing > HDL design, say the top level looks like this (pseudo code, > err myhdl). > > i1 = block_vhdl(...) > i2 = block_vhdl(...) > i3 = block_myhdl_vhdl(...) > > The "i3" module is the "flat" myhdl converted to VHDL. > There are some limitations but not many and most are > manageable. I don't think this should be a concern. I already addressed this on my previous reply. My main concern is that adding a big, flat, automatically generated VHDL file to our VHDL project would be frown upon by the other designers. Do you know something about web technologies? If you do I guess I could say that what I would like to get from MyHDL, compared to VHDL, is akin to what you get from CoffeeScript compared to JavaScript. That is, you get a much nicer language which compiles to idiomatic JavaScript. All this being said, it could seem that I see a lot of problems with using MyHDL. That may be true but I see _a lot_ of potential benefits. That is why I'm thinking hard about how to best minimize the drawbacks while getting most of the benefits. Cheers, Angel |
|
From: Tom D. <td...@di...> - 2012-09-28 13:25:56
|
Angel, My quick answer is to start in one of two areas. 1. Use MyHDL to design and test modules that are included in your VHDL design. Make the modules general purpose with parameters so that they are easily reused. The test bench and module source will be in MyHDL. 2. Use MyHDL as a test bench for existing VHDL modules. You can get far better test coverage quicker with this approach. Of course now we are talking about co-simulation, so you will have to be using a VHDL simulator that is supported or modify an existing interface to work with your simulator (usually not much work). I use Aldec Riviera and it works great. I would start there. Tom On 09/28/2012 02:26 AM, Angel Ezquerra wrote: > Hi, > > For the past couple of years I've been following the MyHDL project > with a lot of interest. I've been subscribed to the mailing list and > followed many of the interesting discussions in here. I've done a few > of the examples on my spare time and I have read the documentation a > couple of times. > > I really like the language. I find it very clear and simply way nicer > than VHDL, which is what we use in our projects where I work. I have > quite a lot of experience with Python, and at work I sometimes use it > with some of its great scientific packages, such as simpy, scipy, > matplotlib, etc, mainly for simulation purposes although most of my > colleagues use Matlab for this. > > That being said, I have trouble coming up with a good way to integrate > MyHDL into our existing workflows. I'm looking for advice here to see > if there is a way that we could use MyHDL to improve our productivity. > > Our current setup is as follows: > > - We use Xilinx FPGAs (Spartan and Virtex 5 and 6 and probably Kintex > or Virtex 7 soon). > - Our firmware code is 100% VHDL. > - We use the latest version of the Xilinx ISE environment (which > unfortunately is pretty weak, specially in the editing and code > exploration departments). > - Some of us are also using the excellent Sigasi editor (which I > discovered thanks to this list). For now we are using the basic > edition which is nice but we hope to be able to buy a few licenses > soon. > - We use some Xilinx IP cores, which come as an NGC plus a VHDL simulation file. > - We receive a basic firmware "shell" from our hardware team, which, > basically, is the top VHDL file of the design. This "shell" sets up > the system clocks, instantiates the different devices that are used to > connect the FPGA firmware to the outside world (i.e. the different > ports, etc), as well as the memories, and other devices that are > present on the FPGA and on its board. > - That "shell" also contains an instance of the actual "top > entity" that is the one that we create. > - They also give us the basic "constraints file" which selects the > pinout, etc. > - We have no control over what we receive from the HW team. We > must use what they give us "as is". > - We do not use any custom TCL scripts to build our firmware. We just > use the ISE "Generate Programming File" command. > - We use either Modelsim or the builtin ISE ISim simulator to run our > simulations. We are exploring the possibility of using Xilinx' new > Vivado Simulator as well. > - We usually create a "high level" Matlab or python based simulation > models of our system. The model is not necessarily bit accurate to the > actual VHDL implementation, but we try to make it so that it is able > to generate the inputs necessary to drive our VHDL test benches > (including configuration and data), and even our compiled firmware > (mostly configuration) > - We create VHDL test benches for most (although sadly not all) of our > modules. These test benches are usually quite simple. They just read > the inputs from some files (generated with our Matlab or python > simulators) and save the outputs so that they can be compared to some > "golden" outputs (usually generated with our high level simulators). > - When there are issues we often use the test benches to simulate > the models and we use the (not so good) visualization capabilities of > Modelsim to debug. > - We also tend to use ChipScope to add "logic analyzer modules" to > our firmware so that we can debug "live" some specially tricky issues. > - We also use a logic analyzer port to output data that is then > captured by an external logic analizer. This is necessary when the > amount of data to capture is so great that it would not fit on a > ChipScope block. > > What we definitely cannot do is introduce huge changes to our > development practices. I am sure that there are plenty of things that > we could do differently and that we should (and probably will) > improve. However I'd like to introduce this new technology gradually, > and once people are more comfortable with it we could do bigger > changes to our work flow. > > The way I see it there are a few barriers that make it hard for us to > use MyHDL. It is likely that some of these are moot (i.e. perhaps when > we start using MyHDL I'll realize that they are not important), but > for now they seem things that we should deal with: > > 1. The MyHDL code may need to interface with existing blocks, > particularly with IP cores. This results in several problems: > - It would make it hard to run simulations on the "MyHDL world" > since we do not have MyHDL models for the Xilinx IP cores. > - I got the impression that the MyHDL to VHDL "interface" is not > that clean and that the process is manual (I have not looked much into > this, so I may be wrong). > 2. We should come up with a way to automatically generate the VHDL > from the MyHDL when we generate our programming file. > 3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim > (at least on Windows). > 4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH > and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD > (and rightly so). There may be issues mixing both sets of libraries. > 5. There is no editor integration (not even with Sigasi). > 6. I believe that the fact that the VHDL code that MyHDL generates is > "flat" is a problem, because it makes it harder to introduce MyHDL > little by little. > - This may be just my perception and turn out to be a non issue, > but I think that if MyHDL generated regular structured code (e.g. if > you could tell MyHDL "place all these processes on a single entity > named foo") it would be much easier to start using MyHDL to create > smaller modules that could be added to our regular VHDL project "as > is". > > There are probably other issues that I have not thought about, and > maybe some of these are not a problem at all. > > I'd like to get your opinions and your advice on whether you think it > makes sense to try to fit MyHDL into our workflow. Perhaps it does not > make sense unless you use MyHDL from start to end, but I hope it is > possible. > > Cheers, > > Angel > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Christopher F. <chr...@gm...> - 2012-09-28 13:54:19
|
On 9/28/2012 8:25 AM, Tom Dillon wrote: > Angel, > > My quick answer is to start in one of two areas. > > 1. Use MyHDL to design and test modules that are included in your VHDL > design. Make the modules general purpose with parameters so that they > are easily reused. The test bench and module source will be in MyHDL. > > 2. Use MyHDL as a test bench for existing VHDL modules. You can get far > better test coverage quicker with this approach. Of course now we are > talking about co-simulation, so you will have to be using a VHDL > simulator that is supported or modify an existing interface to work with > your simulator (usually not much work). I use Aldec Riviera and it works > great. > > I would start there. > > Tom > Tom, Are you using cosimulation with Aldec and VHDL? If so did you have to do small mods for the VHPI interface? Regards, Chris |
|
From: Tom D. <td...@di...> - 2012-09-28 14:21:49
|
On 09/28/2012 08:53 AM, Christopher Felton wrote: > On 9/28/2012 8:25 AM, Tom Dillon wrote: >> Angel, >> >> My quick answer is to start in one of two areas. >> >> 1. Use MyHDL to design and test modules that are included in your VHDL >> design. Make the modules general purpose with parameters so that they >> are easily reused. The test bench and module source will be in MyHDL. >> >> 2. Use MyHDL as a test bench for existing VHDL modules. You can get far >> better test coverage quicker with this approach. Of course now we are >> talking about co-simulation, so you will have to be using a VHDL >> simulator that is supported or modify an existing interface to work with >> your simulator (usually not much work). I use Aldec Riviera and it works >> great. >> >> I would start there. >> >> Tom >> > Tom, > > Are you using cosimulation with Aldec and VHDL? If so did you have to > do small mods for the VHPI interface? > > Regards, > Chris > Chris, Great question. It had been so long since I did that I forgot. I am using VPI (not VHPI) to connect to the Riviera simulator. I have a mixed mode version of Riviera so that allows me to simulate Verilog or VHDL modules. I suspect VHPI would work as well. Tom > > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Christopher F. <chr...@gm...> - 2012-09-28 15:13:21
|
On 9/28/2012 9:21 AM, Tom Dillon wrote: > > On 09/28/2012 08:53 AM, Christopher Felton wrote: >> On 9/28/2012 8:25 AM, Tom Dillon wrote: >>> Angel, >>> >>> My quick answer is to start in one of two areas. >>> >>> 1. Use MyHDL to design and test modules that are included in your VHDL >>> design. Make the modules general purpose with parameters so that they >>> are easily reused. The test bench and module source will be in MyHDL. >>> >>> 2. Use MyHDL as a test bench for existing VHDL modules. You can get far >>> better test coverage quicker with this approach. Of course now we are >>> talking about co-simulation, so you will have to be using a VHDL >>> simulator that is supported or modify an existing interface to work with >>> your simulator (usually not much work). I use Aldec Riviera and it works >>> great. >>> >>> I would start there. >>> >>> Tom >>> >> Tom, >> >> Are you using cosimulation with Aldec and VHDL? If so did you have to >> do small mods for the VHPI interface? >> >> Regards, >> Chris >> > Chris, > > Great question. It had been so long since I did that I forgot. I am > using VPI (not VHPI) to connect to the Riviera simulator. I have a mixed > mode version of Riviera so that allows me to simulate Verilog or VHDL > modules. > > I suspect VHPI would work as well. > > Tom > > Strangely modelsim does not appear to support VPI with VHDL directly, you have to use their FLI interface. But I do not know what happens if you do a mixed Verilog/VHDL sim in Modelsim. My guess is, you have to do a Verilog mixed VHDL sim (top-level Verilog) and it would work. If that is true, the quick path for MyHDL-VHDL cosim would be this approach (mixed verilog/vhdl requires Modelsim SE or Questa). Regards, Chris |
|
From: Angel E. <ang...@gm...> - 2012-10-04 21:02:36
|
Chris, Sorry it took me so long to get back to you. I've been really busy recently. First of all, thanks _a lot_ for taking the time to go through my concerns so carefully. I really appreciate it. See some replies below... On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...> wrote: > On 9/28/2012 7:31 AM, Angel Ezquerra wrote: >> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton >> <chr...@gm...> wrote: >>> On 9/28/2012 2:26 AM, Angel Ezquerra wrote: >>>> Hi, >>>> >>>> For the past couple of years I've been following the MyHDL project >>>> with a lot of interest. I've been subscribed to the mailing list and >>>> followed many of the interesting discussions in here. I've done a few >>>> of the examples on my spare time and I have read the documentation a >>>> couple of times. >>>> >>>> I really like the language. I find it very clear and simply way nicer >>>> than VHDL, which is what we use in our projects where I work. I have >>>> quite a lot of experience with Python, and at work I sometimes use it >>>> with some of its great scientific packages, such as simpy, scipy, >>>> matplotlib, etc, mainly for simulation purposes although most of my >>>> colleagues use Matlab for this. >>>> >>>> That being said, I have trouble coming up with a good way to integrate >>>> MyHDL into our existing workflows. I'm looking for advice here to see >>>> if there is a way that we could use MyHDL to improve our productivity. >>>> >>> <snip> >>> >>> My quick two cents is that you adopt the "IP" developed >>> with MyHDL approach. You start using the tool this way. >>> Your co-workers might never know you are using MyHDL. >> >> I'm not sure I understand what you mean. Do you mean that I would >> write my code on MyHDL, generate the VHDL and publish the generated >> VHDL as an "IP"? > > Essentially, but I don't mean that you have to create a > netlist and integrate. Simply take the generated VHDL > and use in the design. > >> >> If that is the case I fear that the fact that the automatically >> generated code is flat may be a problem. Depending on how big are the >> modules that I work on it the resulting VHDL could be pretty big, >> couldn't it? I guess my colleagues would find that odd :-P > > Why would a large VHDL be an issue? I don't think it > is. If you really need the hierarchy there are options, > just takes a little more work. Could you detail what you mean by it "just takes a little more work"? My ideal workflow would be to be able to add a decorator to some function which would mark a file as describing an entity, which would group all processes defined within it as part of that entity, and which would put that entity on its own file. I think a "large" VHDL is an issue mostly because it would make it much harder to debug using a regular VHDL simulator (e.g. modelsim) and adding debug signals to a chipscope (Xilinx' in FPGA logic analyzer). Additionally, some synthesizers (XST for example) give you options to control how optimizations and routing are handling across entity boundaries. I am by no means an expert of this though. This is just advice I've gotten from more experienced designers than I am. I just know that on a somewhat conservative development team it would be way easier to add to a project a few files that have been automatically generated via MyHDL than adding a single, big, flat file. I know that I would face much more resistance with the single flat file than I would otherwise. Given that I am not the most experienced FW developer in our team it is uncertain that I'd be able to convince the most expert designers that this is not a problem. This is probably a matter of perception, but I am quite sure that this would be a big point against MyHDL. >>> As you indicate, there are some short comings to this >>> approach. One of the items you suggested is using MyHDL >>> for top-level simulation/verification (cosimulation with >>> VHDL). What VHDL simulator are you using? >> >> We currently use Modelsim and ISim, on Windows. > > Isim doesn't support PLI/VPI/DPI/VHPI you won't be able > to do cosim with Isim. There's other interest with mti > VHDL cosim, this has a decent change of being developed. > If that occurs, you can start developing a top-level > verification environment and blow the socks off your > co-workers! They will be utterly amazed. Again, would you mind detailing (or linking to some wiki or post) some examples of what could be achieved? I believe I can imagine what we could do, mostly mixing some cool python modules such as matplotlib with our test benches, but some concrete examples would be nice. Cheers, Angel |
|
From: Christopher F. <chr...@gm...> - 2012-10-09 18:07:58
|
On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
> Chris,
>
> Sorry it took me so long to get back to you. I've been really busy recently.
>
> First of all, thanks _a lot_ for taking the time to go through my concerns
> so carefully. I really appreciate it.
>
> See some replies below...
>
> On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
> wrote:
>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
>>> <chr...@gm...> wrote:
>>>> On 9/28/2012 2:26 AM, Angel Ezquerra wrote:
>>>>> Hi,
>>>>>
>>>>> For the past couple of years I've been following the MyHDL project
>>>>> with a lot of interest. I've been subscribed to the mailing list and
>>>>> followed many of the interesting discussions in here. I've done a few
>>>>> of the examples on my spare time and I have read the documentation a
>>>>> couple of times.
>>>>>
>>>>> I really like the language. I find it very clear and simply way nicer
>>>>> than VHDL, which is what we use in our projects where I work. I have
>>>>> quite a lot of experience with Python, and at work I sometimes use it
>>>>> with some of its great scientific packages, such as simpy, scipy,
>>>>> matplotlib, etc, mainly for simulation purposes although most of my
>>>>> colleagues use Matlab for this.
>>>>>
>>>>> That being said, I have trouble coming up with a good way to integrate
>>>>> MyHDL into our existing workflows. I'm looking for advice here to see
>>>>> if there is a way that we could use MyHDL to improve our productivity.
>>>>>
>>>> <snip>
>>>>
>>>> My quick two cents is that you adopt the "IP" developed
>>>> with MyHDL approach. You start using the tool this way.
>>>> Your co-workers might never know you are using MyHDL.
>>>
>>> I'm not sure I understand what you mean. Do you mean that I would
>>> write my code on MyHDL, generate the VHDL and publish the generated
>>> VHDL as an "IP"?
>>
>> Essentially, but I don't mean that you have to create a
>> netlist and integrate. Simply take the generated VHDL
>> and use in the design.
>>
>>>
>>> If that is the case I fear that the fact that the automatically
>>> generated code is flat may be a problem. Depending on how big are the
>>> modules that I work on it the resulting VHDL could be pretty big,
>>> couldn't it? I guess my colleagues would find that odd :-P
>>
>> Why would a large VHDL be an issue? I don't think it
>> is. If you really need the hierarchy there are options,
>> just takes a little more work.
>
> Could you detail what you mean by it "just takes a little more work"?
Just that, you will need to convert each piece separately
and merge them together. Most of this can be automated
(I believe).
I had a rare case where I wanted to preserve hierarchy
this is how I did it:
toVerilog(submodule, sigs, params)
# move to a new filename with params in the name
submodule.verilog_instance = 'SUB1'
toVerilog(module, sigs, params)
Where "module" instantiates 'submodule". This will stub
out "submodule" in module. It is a little more work
but not bad. I had to add extra to the submodule
def submodule(...):
if hasattr(submodule, "verilog_instance"):
out1.driven = 'wire'
out2.driven = 'wire'
# etc
If you had a design that is more complicated you could
automate the first part. You still would need to add
the output definition in the module (submodule) being
stubbed. The nice thing about the above example, every
thing will be wired up automatically.
Note: I think Jan indicated the verilog_instance might
need some work, use with caution. I have used it
without issue.
> My ideal workflow would be to be able to add a decorator to some function
> which would mark a file as describing an entity, which would group all
> processes defined within it as part of that entity, and which would put
> that entity on its own file.
>
> I think a "large" VHDL is an issue mostly because it would make it much
> harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
> debug signals to a chipscope (Xilinx' in FPGA logic analyzer).
This hasn't been my experience, I have an all MyHDL FPGA
design I use to interface to our mixed-signal ICs (ICs
also utilize MyHDL). I use SignalTap frequently and it
doesn't cause me much heart-ache.
>
> Additionally, some synthesizers (XST for example) give you options to
> control how optimizations and routing are handling across entity
> boundaries. I am by no means an expert of this though. This is just advice
> I've gotten from more experienced designers than I am.
Not sure what the point is or the question you might
be asking? If you describe your design with a lot of
hierarchy it is often beneficial, from a resource /
performance point of view, to optimize across boundaries.
But this breaks the structure and tools like ChipScope
and SignalTap might be more difficult to work with
(not much different than MyHDL flattening).
An interesting case study would be to record the
synthesis results between a hierarchical design,
optimize across,and a MyHDL flattened design.
>
> I just know that on a somewhat conservative development team it would be
> way easier to add to a project a few files that have been automatically
> generated via MyHDL than adding a single, big, flat file. I know that I
> would face much more resistance with the single flat file than I would
> otherwise. Given that I am not the most experienced FW developer in our
> team it is uncertain that I'd be able to convince the most expert designers
> that this is not a problem.
>
> This is probably a matter of perception, but I am quite sure that this
> would be a big point against MyHDL.
I think I might not be following you between "module"
and "files". From my perspective, if you had a new module
that you needed to add, you could implement it in MyHDL
and you would have /one/ new file to add to the design.
Even if the module had many layers of hierarchy, and the
one new file would be minimal impact to the existing flow.
>
>>>> As you indicate, there are some short comings to this
>>>> approach. One of the items you suggested is using MyHDL
>>>> for top-level simulation/verification (cosimulation with
>>>> VHDL). What VHDL simulator are you using?
>>>
>>> We currently use Modelsim and ISim, on Windows.
>>
>> Isim doesn't support PLI/VPI/DPI/VHPI you won't be able
>> to do cosim with Isim. There's other interest with mti
>> VHDL cosim, this has a decent change of being developed.
>> If that occurs, you can start developing a top-level
>> verification environment and blow the socks off your
>> co-workers! They will be utterly amazed.
>
> Again, would you mind detailing (or linking to some wiki or post) some
> examples of what could be achieved? I believe I can imagine what we could
> do, mostly mixing some cool python modules such as matplotlib with our test
> benches, but some concrete examples would be nice.
>
> Cheers,
>
> Angel
>
|
|
From: Angel E. <ang...@gm...> - 2012-10-10 06:59:23
|
Hi again Chris,
thank you for your replies. See my comments below.
On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton
<chr...@gm...> wrote:
> On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
>> Chris,
>>
>> Sorry it took me so long to get back to you. I've been really busy recently.
>>
>> First of all, thanks _a lot_ for taking the time to go through my concerns
>> so carefully. I really appreciate it.
>>
>> See some replies below...
>>
>> On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
>> wrote:
>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
[...]
>>> Why would a large VHDL be an issue? I don't think it
>>> is. If you really need the hierarchy there are options,
>>> just takes a little more work.
>>
>> Could you detail what you mean by it "just takes a little more work"?
>
> Just that, you will need to convert each piece separately
> and merge them together. Most of this can be automated
> (I believe).
>
> I had a rare case where I wanted to preserve hierarchy
> this is how I did it:
>
> toVerilog(submodule, sigs, params)
> # move to a new filename with params in the name
Sorry, maybe I'm a bit thick but I don't know what you mean by "move
to a new filename with params in the name"
> submodule.verilog_instance = 'SUB1'
> toVerilog(module, sigs, params)
>
> Where "module" instantiates 'submodule". This will stub
> out "submodule" in module. It is a little more work
> but not bad. I had to add extra to the submodule
>
> def submodule(...):
> if hasattr(submodule, "verilog_instance"):
> out1.driven = 'wire'
> out2.driven = 'wire'
> # etc
I don't know what "verilog_instance" does. I guess there is an
equivalent "vhdl_instance"? I looked for it on google but I did not
get any useful results. I also don't know why you need to set the
"driven" attribute.
I feel as if these questions are very basic and I should know them...
Is there some documentation on these features that I missed?
> If you had a design that is more complicated you could
> automate the first part. You still would need to add
> the output definition in the module (submodule) being
> stubbed. The nice thing about the above example, every
> thing will be wired up automatically.
>
> Note: I think Jan indicated the verilog_instance might
> need some work, use with caution. I have used it
> without issue.
As I said I don't really know what these do so I don't think I could
use them, even cautiously :-> It still seems a bit too complicated for
my taste though.
Anyway, since this process seems easy to automate (I can't really
tell, since I don't really understand it), the obvious question is why
not make MyHDL itself automate it for us? That should put to rest the
question of generating hierarchical VHDL or Verilog code which seems
to crop up regularly on this list and on other online discussions
about MyHDL!
>> My ideal workflow would be to be able to add a decorator to some function
>> which would mark a file as describing an entity, which would group all
>> processes defined within it as part of that entity, and which would put
>> that entity on its own file.
>>
>> I think a "large" VHDL is an issue mostly because it would make it much
>> harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
>> debug signals to a chipscope (Xilinx' in FPGA logic analyzer).
>
> This hasn't been my experience, I have an all MyHDL FPGA
> design I use to interface to our mixed-signal ICs (ICs
> also utilize MyHDL). I use SignalTap frequently and it
> doesn't cause me much heart-ache.
Glad to know that. Maybe my intuition is wrong then... Still I
anticipate that you would still need to look into the generated VHDL
from time to time, possibly using (the terrible) ISE editor. In there
you'd see a single entity on the hierarchy view. I'd definitely prefer
to get a proper hierarchy in there instead.
>> Additionally, some synthesizers (XST for example) give you options to
>> control how optimizations and routing are handling across entity
>> boundaries. I am by no means an expert of this though. This is just advice
>> I've gotten from more experienced designers than I am.
>
> Not sure what the point is or the question you might
> be asking? If you describe your design with a lot of
> hierarchy it is often beneficial, from a resource /
> performance point of view, to optimize across boundaries.
> But this breaks the structure and tools like ChipScope
> and SignalTap might be more difficult to work with
> (not much different than MyHDL flattening).
>
> An interesting case study would be to record the
> synthesis results between a hierarchical design,
> optimize across,and a MyHDL flattened design.
That could be interesting although given that Xilinx XST will
sometimes give you a different result when you implement the same code
twice I would not put that much faith on the comparison results...
Sometimes I feel that the Xilinx uses the position of the stars and
the phase of the moon to decide how to synthesize their FPGAs :-P
>> I just know that on a somewhat conservative development team it would be
>> way easier to add to a project a few files that have been automatically
>> generated via MyHDL than adding a single, big, flat file. I know that I
>> would face much more resistance with the single flat file than I would
>> otherwise. Given that I am not the most experienced FW developer in our
>> team it is uncertain that I'd be able to convince the most expert designers
>> that this is not a problem.
>>
>> This is probably a matter of perception, but I am quite sure that this
>> would be a big point against MyHDL.
>
> I think I might not be following you between "module"
> and "files". From my perspective, if you had a new module
> that you needed to add, you could implement it in MyHDL
> and you would have /one/ new file to add to the design.
> Even if the module had many layers of hierarchy, and the
> one new file would be minimal impact to the existing flow.
Now I am not sure that I understand you. By module I mean a VHDL
entity and by file I mean, well, a file :-)
The issue I state is that adding a _single_, big, MyHDL generated VHDL
file to an existing VHDL project would be a problem. The problem is
not technical (or at least not mainly technical) but "social". I think
that when working on a project with multiple designers they would not
easily accept me adding a single file that implemented a significant
part of the design particularly if they knew that the file had been
automatically generated. They would ask me to "modularize" my
contribution. According to what you said above that is something that
can be done but it requires (unnecessary?) extra work with the current
version of MyHDL.
In my experience many FW designers are surprisingly risk averse and
not prone to try new design tools and approaches. That is an
unfortunate barrier to entry that MyHDL must go through.
If MyHDL let me group part of my MyHDL design in entities or packages,
which were saved into separate files when generating the VHDL or
Verilog code, this problem would be gone. IMHO this would make it much
easier ("socially") to introduce VHDL into an existing, VHDL or
Verilog based, project.
It may seem that I am blowing this issue out of proportion, but I know
the people I've worked with and I'm pretty sure these concerns are
real.
Cheers,
Angel
|
|
From: Christopher F. <chr...@gm...> - 2012-10-10 10:21:12
|
On 10/10/12 1:59 AM, Angel Ezquerra wrote:
> Hi again Chris,
>
> thank you for your replies. See my comments below.
>
> On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton
> <chr...@gm...> wrote:
>> On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
>>> Chris,
>>>
>>> Sorry it took me so long to get back to you. I've been really busy recently.
>>>
>>> First of all, thanks _a lot_ for taking the time to go through my concerns
>>> so carefully. I really appreciate it.
>>>
>>> See some replies below...
>>>
>>> On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
>>> wrote:
>>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
>>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
> [...]
>>>> Why would a large VHDL be an issue? I don't think it
>>>> is. If you really need the hierarchy there are options,
>>>> just takes a little more work.
>>>
>>> Could you detail what you mean by it "just takes a little more work"?
>>
>> Just that, you will need to convert each piece separately
>> and merge them together. Most of this can be automated
>> (I believe).
>>
>> I had a rare case where I wanted to preserve hierarchy
>> this is how I did it:
>>
>> toVerilog(submodule, sigs, params)
>> # move to a new filename with params in the name
>
> Sorry, maybe I'm a bit thick but I don't know what you mean by "move
> to a new filename with params in the name"
When converting a module it has a "default" filename. In
this case I wanted a filename that represented the parameters
used to generated the module.
>
>> submodule.verilog_instance = 'SUB1'
>> toVerilog(module, sigs, params)
>>
>> Where "module" instantiates 'submodule". This will stub
>> out "submodule" in module. It is a little more work
>> but not bad. I had to add extra to the submodule
>>
>> def submodule(...):
>> if hasattr(submodule, "verilog_instance"):
>> out1.driven = 'wire'
>> out2.driven = 'wire'
>> # etc
>
> I don't know what "verilog_instance" does. I guess there is an
> equivalent "vhdl_instance"? I looked for it on google but I did not
> get any useful results. I also don't know why you need to set the
> "driven" attribute.
The "*_instance" isn't currently documented in the
manual. It is something that has been discussed on
the mailing list. This is a discussion of methods
that might be possible. It is not intended to be
cookbook solution to a specific problem.
>
> I feel as if these questions are very basic and I should know them...
> Is there some documentation on these features that I missed?
>
>> If you had a design that is more complicated you could
>> automate the first part. You still would need to add
>> the output definition in the module (submodule) being
>> stubbed. The nice thing about the above example, every
>> thing will be wired up automatically.
>>
>> Note: I think Jan indicated the verilog_instance might
>> need some work, use with caution. I have used it
>> without issue.
>
> As I said I don't really know what these do so I don't think I could
> use them, even cautiously :-> It still seems a bit too complicated for
> my taste though.
That is a haste judgement. If you don't know what
it is how can you objectively comment that it is too
complicated?
>
> Anyway, since this process seems easy to automate (I can't really
> tell, since I don't really understand it), the obvious question is why
> not make MyHDL itself automate it for us? That should put to rest the
> question of generating hierarchical VHDL or Verilog code which seems
> to crop up regularly on this list and on other online discussions
> about MyHDL!
The obvious question is why someone interested in a
feature doesn't propose a MEP and a patch?
>
>
>>> My ideal workflow would be to be able to add a decorator to some function
>>> which would mark a file as describing an entity, which would group all
>>> processes defined within it as part of that entity, and which would put
>>> that entity on its own file.
>>>
>>> I think a "large" VHDL is an issue mostly because it would make it much
>>> harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
>>> debug signals to a chipscope (Xilinx' in FPGA logic analyzer).
>>
>> This hasn't been my experience, I have an all MyHDL FPGA
>> design I use to interface to our mixed-signal ICs (ICs
>> also utilize MyHDL). I use SignalTap frequently and it
>> doesn't cause me much heart-ache.
>
> Glad to know that. Maybe my intuition is wrong then... Still I
> anticipate that you would still need to look into the generated VHDL
> from time to time, possibly using (the terrible) ISE editor. In there
> you'd see a single entity on the hierarchy view. I'd definitely prefer
> to get a proper hierarchy in there instead.
>
>>> Additionally, some synthesizers (XST for example) give you options to
>>> control how optimizations and routing are handling across entity
>>> boundaries. I am by no means an expert of this though. This is just advice
>>> I've gotten from more experienced designers than I am.
>>
>> Not sure what the point is or the question you might
>> be asking? If you describe your design with a lot of
>> hierarchy it is often beneficial, from a resource /
>> performance point of view, to optimize across boundaries.
>> But this breaks the structure and tools like ChipScope
>> and SignalTap might be more difficult to work with
>> (not much different than MyHDL flattening).
>>
>> An interesting case study would be to record the
>> synthesis results between a hierarchical design,
>> optimize across,and a MyHDL flattened design.
>
> That could be interesting although given that Xilinx XST will
> sometimes give you a different result when you implement the same code
> twice I would not put that much faith on the comparison results...
> Sometimes I feel that the Xilinx uses the position of the stars and
> the phase of the moon to decide how to synthesize their FPGAs :-P
No, you should get consistent results from synthesis,
you might get varying timing from PaR but functionally
it should not change. I have not noticed resource
changes from synthesis run to synthesis run.
>
>>> I just know that on a somewhat conservative development team it would be
>>> way easier to add to a project a few files that have been automatically
>>> generated via MyHDL than adding a single, big, flat file. I know that I
>>> would face much more resistance with the single flat file than I would
>>> otherwise. Given that I am not the most experienced FW developer in our
>>> team it is uncertain that I'd be able to convince the most expert designers
>>> that this is not a problem.
>>>
>>> This is probably a matter of perception, but I am quite sure that this
>>> would be a big point against MyHDL.
>>
>> I think I might not be following you between "module"
>> and "files". From my perspective, if you had a new module
>> that you needed to add, you could implement it in MyHDL
>> and you would have /one/ new file to add to the design.
>> Even if the module had many layers of hierarchy, and the
>> one new file would be minimal impact to the existing flow.
>
> Now I am not sure that I understand you. By module I mean a VHDL
> entity and by file I mean, well, a file :-)
>
> The issue I state is that adding a _single_, big, MyHDL generated VHDL
> file to an existing VHDL project would be a problem. The problem is
> not technical (or at least not mainly technical) but "social". I think
> that when working on a project with multiple designers they would not
> easily accept me adding a single file that implemented a significant
> part of the design particularly if they knew that the file had been
> automatically generated. They would ask me to "modularize" my
> contribution. According to what you said above that is something that
> can be done but it requires (unnecessary?) extra work with the current
> version of MyHDL.
>
> In my experience many FW designers are surprisingly risk averse and
> not prone to try new design tools and approaches. That is an
> unfortunate barrier to entry that MyHDL must go through.
>
> If MyHDL let me group part of my MyHDL design in entities or packages,
> which were saved into separate files when generating the VHDL or
> Verilog code, this problem would be gone. IMHO this would make it much
> easier ("socially") to introduce VHDL into an existing, VHDL or
> Verilog based, project.
>
> It may seem that I am blowing this issue out of proportion, but I know
> the people I've worked with and I'm pretty sure these concerns are
> real.
>
> Cheers,
>
> Angel
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
|
|
From: Angel E. <ang...@gm...> - 2012-10-10 10:47:25
|
Hi again Chris, see my replies below. On Wed, Oct 10, 2012 at 12:20 PM, Christopher Felton <chr...@gm...> wrote: > On 10/10/12 1:59 AM, Angel Ezquerra wrote: >> On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton >> <chr...@gm...> wrote: >>> On 10/4/2012 4:02 PM, Angel Ezquerra wrote: [...] >>>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote: >>>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton >> [...] >>>>> Why would a large VHDL be an issue? I don't think it >>>>> is. If you really need the hierarchy there are options, >>>>> just takes a little more work. >>>> >>>> Could you detail what you mean by it "just takes a little more work"? >>> >>> Just that, you will need to convert each piece separately >>> and merge them together. Most of this can be automated >>> (I believe). >>> >>> I had a rare case where I wanted to preserve hierarchy >>> this is how I did it: >>> >>> toVerilog(submodule, sigs, params) >>> # move to a new filename with params in the name >> >> Sorry, maybe I'm a bit thick but I don't know what you mean by "move >> to a new filename with params in the name" > > When converting a module it has a "default" filename. In > this case I wanted a filename that represented the parameters > used to generated the module. OK, I understand. >>> submodule.verilog_instance = 'SUB1' >>> toVerilog(module, sigs, params) >>> >>> Where "module" instantiates 'submodule". This will stub >>> out "submodule" in module. It is a little more work >>> but not bad. I had to add extra to the submodule >>> >>> def submodule(...): >>> if hasattr(submodule, "verilog_instance"): >>> out1.driven = 'wire' >>> out2.driven = 'wire' >>> # etc >> >> I don't know what "verilog_instance" does. I guess there is an >> equivalent "vhdl_instance"? I looked for it on google but I did not >> get any useful results. I also don't know why you need to set the >> "driven" attribute. > > The "*_instance" isn't currently documented in the > manual. It is something that has been discussed on > the mailing list. This is a discussion of methods > that might be possible. It is not intended to be > cookbook solution to a specific problem. I see. But can you give the the gist of what it is supposed to do? Or perhaps a link to the particular thread on the mailing list? >> I feel as if these questions are very basic and I should know them... >> Is there some documentation on these features that I missed? >> >>> If you had a design that is more complicated you could >>> automate the first part. You still would need to add >>> the output definition in the module (submodule) being >>> stubbed. The nice thing about the above example, every >>> thing will be wired up automatically. >>> >>> Note: I think Jan indicated the verilog_instance might >>> need some work, use with caution. I have used it >>> without issue. >> >> As I said I don't really know what these do so I don't think I could >> use them, even cautiously :-> It still seems a bit too complicated for >> my taste though. > > That is a haste judgement. If you don't know what > it is how can you objectively comment that it is too > complicated? I don't fully understand each of the steps that you proposed but I see the amount of steps per submodule. If you wanted to do this for a large design with a fair amount of submodules the amount of steps would be great, wouldn't it? >> Anyway, since this process seems easy to automate (I can't really >> tell, since I don't really understand it), the obvious question is why >> not make MyHDL itself automate it for us? That should put to rest the >> question of generating hierarchical VHDL or Verilog code which seems >> to crop up regularly on this list and on other online discussions >> about MyHDL! > > The obvious question is why someone interested in a > feature doesn't propose a MEP and a patch? That is a fair point. I am still "testing the waters" with MyHDL so to speak, so for now I am just raising the concerns that I come up with. I could try to write a MEP but first I'd like to see if there is some consensus that this could be a worthy idea (as I believe it is). Also, what would be the preferred way to indicate that a group of generators should be grouped into an entity and placed on their own file? For example, in the case that you described, imagine that you had had a magic wand that let you modify MyHDL in a way that you could have avoided all the manual work involved in solving your problem. How would you have liked to be able to tell MyHDL that you wanted to place "submodule" on its own file? Contributing a patch is another matter though. I am quite busy contributing to TortoiseHg at the moment and I don't know how complex the MyHDL code base is. I don't know that I'd have the time to dig deep enough into it to contribute such a patch. >> That could be interesting although given that Xilinx XST will >> sometimes give you a different result when you implement the same code >> twice I would not put that much faith on the comparison results... >> Sometimes I feel that the Xilinx uses the position of the stars and >> the phase of the moon to decide how to synthesize their FPGAs :-P > > No, you should get consistent results from synthesis, > you might get varying timing from PaR but functionally > it should not change. I have not noticed resource > changes from synthesis run to synthesis run. That was meant as a point in cheek comment about how finicky the Xilinx tools are. Sorry if that was not clear. Cheers, Angel |
|
From: Christopher F. <chr...@gm...> - 2012-10-10 12:10:02
|
On 10/10/2012 5:47 AM, Angel Ezquerra wrote: <snip> >> >> The "*_instance" isn't currently documented in the >> manual. It is something that has been discussed on >> the mailing list. This is a discussion of methods >> that might be possible. It is not intended to be >> cookbook solution to a specific problem. > > I see. But can you give the the gist of what it is supposed to do? Or > perhaps a link to the particular thread on the mailing list? > This thread: http://article.gmane.org/gmane.comp.python.myhdl/1484/match=vhdl_instance has some information. Note, I simply went to the gmane myhdl page and did a search. http://search.gmane.org/?query=vhdl_instance&group=gmane.comp.python.myhdl But At this point, direct hierarchical conversion is *not* supported and I don't know of anyone who has automated the manual process. I can only contrive possible solutions. If you are looking for working known solutions, they *don't exist*. There are not specific threads and no other information (as far as I know). At this point in time what you are looking for is not supported. Will it be supported in the future? I don't know. It seems reasonable but there are not the resources to implement it. Regards, Chris |
|
From: Christopher F. <chr...@gm...> - 2012-10-10 12:26:24
|
<snip>
>
>
>>> Anyway, since this process seems easy to automate (I can't really
>>> tell, since I don't really understand it), the obvious question is why
>>> not make MyHDL itself automate it for us? That should put to rest the
>>> question of generating hierarchical VHDL or Verilog code which seems
>>> to crop up regularly on this list and on other online discussions
>>> about MyHDL!
>>
>> The obvious question is why someone interested in a
>> feature doesn't propose a MEP and a patch?
>
> That is a fair point. I am still "testing the waters" with MyHDL so to
> speak, so for now I am just raising the concerns that I come up with.
>
> I could try to write a MEP but first I'd like to see if there is some
> consensus that this could be a worthy idea (as I believe it is). Also,
> what would be the preferred way to indicate that a group of generators
> should be grouped into an entity and placed on their own file?
>
> For example, in the case that you described, imagine that you had had
> a magic wand that let you modify MyHDL in a way that you could have
> avoided all the manual work involved in solving your problem. How
> would you have liked to be able to tell MyHDL that you wanted to place
> "submodule" on its own file?
>
> Contributing a patch is another matter though. I am quite busy
> contributing to TortoiseHg at the moment and I don't know how complex
> the MyHDL code base is. I don't know that I'd have the time to dig
> deep enough into it to contribute such a patch.
>
I am having a hard time following you. At one point
you comment
"since this process seems easy to automate ..."
then you comment
"... the amount of steps would be great"
(implying difficulty)
But if it is easy to automate why would we be concerned
with the number of steps?
I also get confused if you are only interested in an
existing solution or you are willing to experiment and
be part of a development. This conversation seems to
bounce back and forth between wanting a working solution
and "testing the waters". I am never sure which I am
replying to. Given the comments above, I assume you
are mainly interested in existing and working solutions.
Maintaining hierarchy during conversion is a reasonable
feature request. But the priority of the feature? And
the best path forward? I think it is safe to say, given
the resources available this feature will not be added
any time soon. I think you are simply trying to stimulate
conversation and ideas (which is good!). But I don't believe
anyone has the bandwidth to experiment and implement the
feature.
Regards,
Chris
|
|
From: Angel E. <ang...@gm...> - 2012-10-10 15:46:30
|
On Wed, Oct 10, 2012 at 2:25 PM, Christopher Felton <chr...@gm...> wrote: > <snip> >> >> >>>> Anyway, since this process seems easy to automate (I can't really >>>> tell, since I don't really understand it), the obvious question is why >>>> not make MyHDL itself automate it for us? That should put to rest the >>>> question of generating hierarchical VHDL or Verilog code which seems >>>> to crop up regularly on this list and on other online discussions >>>> about MyHDL! >>> >>> The obvious question is why someone interested in a >>> feature doesn't propose a MEP and a patch? >> >> That is a fair point. I am still "testing the waters" with MyHDL so to >> speak, so for now I am just raising the concerns that I come up with. >> >> I could try to write a MEP but first I'd like to see if there is some >> consensus that this could be a worthy idea (as I believe it is). Also, >> what would be the preferred way to indicate that a group of generators >> should be grouped into an entity and placed on their own file? >> >> For example, in the case that you described, imagine that you had had >> a magic wand that let you modify MyHDL in a way that you could have >> avoided all the manual work involved in solving your problem. How >> would you have liked to be able to tell MyHDL that you wanted to place >> "submodule" on its own file? >> >> Contributing a patch is another matter though. I am quite busy >> contributing to TortoiseHg at the moment and I don't know how complex >> the MyHDL code base is. I don't know that I'd have the time to dig >> deep enough into it to contribute such a patch. >> > > I am having a hard time following you. At one point > you comment > > "since this process seems easy to automate ..." > > then you comment > > "... the amount of steps would be great" > (implying difficulty) > > But if it is easy to automate why would we be concerned > with the number of steps? I should have been more clear: - The process "seems easy to automate" according to what you said. - But it _currently_ requires a great number of steps since it must be performed _manually_ (which does not necessarily mean that it would be hard, just tiresome). That is, currently MyHDL does not provide a way to make this without too much effort, but apparently (from what you said) it should be possible to make it automatic. > I also get confused if you are only interested in an > existing solution or you are willing to experiment and > be part of a development. This conversation seems to > bounce back and forth between wanting a working solution > and "testing the waters". I am never sure which I am > replying to. Given the comments above, I assume you > are mainly interested in existing and working solutions. > > Maintaining hierarchy during conversion is a reasonable > feature request. But the priority of the feature? And > the best path forward? I think it is safe to say, given > the resources available this feature will not be added > any time soon. I think you are simply trying to stimulate > conversation and ideas (which is good!). But I don't believe > anyone has the bandwidth to experiment and implement the > feature. I'm mostly interested on working solutions, but since it seems there are none (at least not experimental ones), I want to spur the conversation some and show that there are people (at least one! :-) interested on this feature. As for contributing I have a few small patches ready that I will send to the list shortly. These address some of small issues regarding VHDL code generation that I identified on another email. Cheers, Angel |
|
From: Christopher F. <chr...@gm...> - 2012-10-10 15:57:07
|
On 10/10/2012 10:46 AM, Angel Ezquerra wrote: > On Wed, Oct 10, 2012 at 2:25 PM, Christopher Felton > <chr...@gm...> wrote: >> <snip> >>> >>> >>>>> Anyway, since this process seems easy to automate (I can't really >>>>> tell, since I don't really understand it), the obvious question is why >>>>> not make MyHDL itself automate it for us? That should put to rest the >>>>> question of generating hierarchical VHDL or Verilog code which seems >>>>> to crop up regularly on this list and on other online discussions >>>>> about MyHDL! >>>> >>>> The obvious question is why someone interested in a >>>> feature doesn't propose a MEP and a patch? >>> >>> That is a fair point. I am still "testing the waters" with MyHDL so to >>> speak, so for now I am just raising the concerns that I come up with. >>> >>> I could try to write a MEP but first I'd like to see if there is some >>> consensus that this could be a worthy idea (as I believe it is). Also, >>> what would be the preferred way to indicate that a group of generators >>> should be grouped into an entity and placed on their own file? >>> >>> For example, in the case that you described, imagine that you had had >>> a magic wand that let you modify MyHDL in a way that you could have >>> avoided all the manual work involved in solving your problem. How >>> would you have liked to be able to tell MyHDL that you wanted to place >>> "submodule" on its own file? >>> >>> Contributing a patch is another matter though. I am quite busy >>> contributing to TortoiseHg at the moment and I don't know how complex >>> the MyHDL code base is. I don't know that I'd have the time to dig >>> deep enough into it to contribute such a patch. >>> >> >> I am having a hard time following you. At one point >> you comment >> >> "since this process seems easy to automate ..." >> >> then you comment >> >> "... the amount of steps would be great" >> (implying difficulty) >> >> But if it is easy to automate why would we be concerned >> with the number of steps? > > I should have been more clear: > - The process "seems easy to automate" according to what you said. > - But it _currently_ requires a great number of steps since it must be > performed _manually_ (which does not necessarily mean that it would be > hard, just tiresome). > > That is, currently MyHDL does not provide a way to make this without > too much effort, but apparently (from what you said) it should be > possible to make it automatic. > >> I also get confused if you are only interested in an >> existing solution or you are willing to experiment and >> be part of a development. This conversation seems to >> bounce back and forth between wanting a working solution >> and "testing the waters". I am never sure which I am >> replying to. Given the comments above, I assume you >> are mainly interested in existing and working solutions. >> >> Maintaining hierarchy during conversion is a reasonable >> feature request. But the priority of the feature? And >> the best path forward? I think it is safe to say, given >> the resources available this feature will not be added >> any time soon. I think you are simply trying to stimulate >> conversation and ideas (which is good!). But I don't believe >> anyone has the bandwidth to experiment and implement the >> feature. > > I'm mostly interested on working solutions, but since it seems there > are none (at least not experimental ones), I want to spur the > conversation some and show that there are people (at least one! :-) > interested on this feature. > > As for contributing I have a few small patches ready that I will send > to the list shortly. These address some of small issues regarding VHDL > code generation that I identified on another email. > > Cheers, > > Angel > Angel, Make sure you review the "Guide for Developers": http://www.myhdl.org/doku.php/dev:patches Jan D. has put together a comprehensive guide for contributing to the project. Also note, Jan D. has the final say on all bundles submitted. Thanks for interest in contributing! Regards, Chris |
|
From: Angel E. <ang...@gm...> - 2012-10-10 16:05:08
|
On Wed, Oct 10, 2012 at 5:56 PM, Christopher Felton <chr...@gm...> wrote: > On 10/10/2012 10:46 AM, Angel Ezquerra wrote: >> On Wed, Oct 10, 2012 at 2:25 PM, Christopher Felton >> <chr...@gm...> wrote: >>> <snip> >>>> >>>> >>>>>> Anyway, since this process seems easy to automate (I can't really >>>>>> tell, since I don't really understand it), the obvious question is why >>>>>> not make MyHDL itself automate it for us? That should put to rest the >>>>>> question of generating hierarchical VHDL or Verilog code which seems >>>>>> to crop up regularly on this list and on other online discussions >>>>>> about MyHDL! >>>>> >>>>> The obvious question is why someone interested in a >>>>> feature doesn't propose a MEP and a patch? >>>> >>>> That is a fair point. I am still "testing the waters" with MyHDL so to >>>> speak, so for now I am just raising the concerns that I come up with. >>>> >>>> I could try to write a MEP but first I'd like to see if there is some >>>> consensus that this could be a worthy idea (as I believe it is). Also, >>>> what would be the preferred way to indicate that a group of generators >>>> should be grouped into an entity and placed on their own file? >>>> >>>> For example, in the case that you described, imagine that you had had >>>> a magic wand that let you modify MyHDL in a way that you could have >>>> avoided all the manual work involved in solving your problem. How >>>> would you have liked to be able to tell MyHDL that you wanted to place >>>> "submodule" on its own file? >>>> >>>> Contributing a patch is another matter though. I am quite busy >>>> contributing to TortoiseHg at the moment and I don't know how complex >>>> the MyHDL code base is. I don't know that I'd have the time to dig >>>> deep enough into it to contribute such a patch. >>>> >>> >>> I am having a hard time following you. At one point >>> you comment >>> >>> "since this process seems easy to automate ..." >>> >>> then you comment >>> >>> "... the amount of steps would be great" >>> (implying difficulty) >>> >>> But if it is easy to automate why would we be concerned >>> with the number of steps? >> >> I should have been more clear: >> - The process "seems easy to automate" according to what you said. >> - But it _currently_ requires a great number of steps since it must be >> performed _manually_ (which does not necessarily mean that it would be >> hard, just tiresome). >> >> That is, currently MyHDL does not provide a way to make this without >> too much effort, but apparently (from what you said) it should be >> possible to make it automatic. >> >>> I also get confused if you are only interested in an >>> existing solution or you are willing to experiment and >>> be part of a development. This conversation seems to >>> bounce back and forth between wanting a working solution >>> and "testing the waters". I am never sure which I am >>> replying to. Given the comments above, I assume you >>> are mainly interested in existing and working solutions. >>> >>> Maintaining hierarchy during conversion is a reasonable >>> feature request. But the priority of the feature? And >>> the best path forward? I think it is safe to say, given >>> the resources available this feature will not be added >>> any time soon. I think you are simply trying to stimulate >>> conversation and ideas (which is good!). But I don't believe >>> anyone has the bandwidth to experiment and implement the >>> feature. >> >> I'm mostly interested on working solutions, but since it seems there >> are none (at least not experimental ones), I want to spur the >> conversation some and show that there are people (at least one! :-) >> interested on this feature. >> >> As for contributing I have a few small patches ready that I will send >> to the list shortly. These address some of small issues regarding VHDL >> code generation that I identified on another email. >> >> Cheers, >> >> Angel >> > > Angel, > > Make sure you review the "Guide for Developers": > http://www.myhdl.org/doku.php/dev:patches > > Jan D. has put together a comprehensive guide for contributing > to the project. > > Also note, Jan D. has the final say on all bundles submitted. > > Thanks for interest in contributing! > > Regards, > Chris OK, I did not know about that document. Sorry. Apparently it seems Jan prefers to receive bundles directly on his email address. I sent a patch series to the list because that is the way things are done on the tortoisehg and on the mercurial mailing list itself. The document seems to suggest that it is ok to send patches to the list for discussion though, so I guess what I did is kind of ok. Cheers, Angel |
|
From: Christopher F. <chr...@gm...> - 2012-10-10 16:09:27
|
On 10/10/2012 11:04 AM, Angel Ezquerra wrote: > On Wed, Oct 10, 2012 at 5:56 PM, Christopher Felton > <chr...@gm...> wrote: >> On 10/10/2012 10:46 AM, Angel Ezquerra wrote: >>> On Wed, Oct 10, 2012 at 2:25 PM, Christopher Felton >>> <chr...@gm...> wrote: >>>> <snip> >>>>> >>>>> >>>>>>> Anyway, since this process seems easy to automate (I can't really >>>>>>> tell, since I don't really understand it), the obvious question is why >>>>>>> not make MyHDL itself automate it for us? That should put to rest the >>>>>>> question of generating hierarchical VHDL or Verilog code which seems >>>>>>> to crop up regularly on this list and on other online discussions >>>>>>> about MyHDL! >>>>>> >>>>>> The obvious question is why someone interested in a >>>>>> feature doesn't propose a MEP and a patch? >>>>> >>>>> That is a fair point. I am still "testing the waters" with MyHDL so to >>>>> speak, so for now I am just raising the concerns that I come up with. >>>>> >>>>> I could try to write a MEP but first I'd like to see if there is some >>>>> consensus that this could be a worthy idea (as I believe it is). Also, >>>>> what would be the preferred way to indicate that a group of generators >>>>> should be grouped into an entity and placed on their own file? >>>>> >>>>> For example, in the case that you described, imagine that you had had >>>>> a magic wand that let you modify MyHDL in a way that you could have >>>>> avoided all the manual work involved in solving your problem. How >>>>> would you have liked to be able to tell MyHDL that you wanted to place >>>>> "submodule" on its own file? >>>>> >>>>> Contributing a patch is another matter though. I am quite busy >>>>> contributing to TortoiseHg at the moment and I don't know how complex >>>>> the MyHDL code base is. I don't know that I'd have the time to dig >>>>> deep enough into it to contribute such a patch. >>>>> >>>> >>>> I am having a hard time following you. At one point >>>> you comment >>>> >>>> "since this process seems easy to automate ..." >>>> >>>> then you comment >>>> >>>> "... the amount of steps would be great" >>>> (implying difficulty) >>>> >>>> But if it is easy to automate why would we be concerned >>>> with the number of steps? >>> >>> I should have been more clear: >>> - The process "seems easy to automate" according to what you said. >>> - But it _currently_ requires a great number of steps since it must be >>> performed _manually_ (which does not necessarily mean that it would be >>> hard, just tiresome). >>> >>> That is, currently MyHDL does not provide a way to make this without >>> too much effort, but apparently (from what you said) it should be >>> possible to make it automatic. >>> >>>> I also get confused if you are only interested in an >>>> existing solution or you are willing to experiment and >>>> be part of a development. This conversation seems to >>>> bounce back and forth between wanting a working solution >>>> and "testing the waters". I am never sure which I am >>>> replying to. Given the comments above, I assume you >>>> are mainly interested in existing and working solutions. >>>> >>>> Maintaining hierarchy during conversion is a reasonable >>>> feature request. But the priority of the feature? And >>>> the best path forward? I think it is safe to say, given >>>> the resources available this feature will not be added >>>> any time soon. I think you are simply trying to stimulate >>>> conversation and ideas (which is good!). But I don't believe >>>> anyone has the bandwidth to experiment and implement the >>>> feature. >>> >>> I'm mostly interested on working solutions, but since it seems there >>> are none (at least not experimental ones), I want to spur the >>> conversation some and show that there are people (at least one! :-) >>> interested on this feature. >>> >>> As for contributing I have a few small patches ready that I will send >>> to the list shortly. These address some of small issues regarding VHDL >>> code generation that I identified on another email. >>> >>> Cheers, >>> >>> Angel >>> >> >> Angel, >> >> Make sure you review the "Guide for Developers": >> http://www.myhdl.org/doku.php/dev:patches >> >> Jan D. has put together a comprehensive guide for contributing >> to the project. >> >> Also note, Jan D. has the final say on all bundles submitted. >> >> Thanks for interest in contributing! >> >> Regards, >> Chris > > OK, I did not know about that document. Sorry. > > Apparently it seems Jan prefers to receive bundles directly on his > email address. I sent a patch series to the list because that is the > way things are done on the tortoisehg and on the mercurial mailing > list itself. The document seems to suggest that it is ok to send > patches to the list for discussion though, so I guess what I did is > kind of ok. > > Cheers, > > Angel > I usually send patches/bundles directly to the mailing-list (good or bad). The issue can be if it is large for some reason. I don't believe it is bad to send patches to the mailing-list. .chris |
|
From: Angel E. <ang...@gm...> - 2012-10-10 16:35:22
|
On Wed, Oct 10, 2012 at 6:09 PM, Christopher Felton <chr...@gm...> wrote: > On 10/10/2012 11:04 AM, Angel Ezquerra wrote: >> On Wed, Oct 10, 2012 at 5:56 PM, Christopher Felton >> <chr...@gm...> wrote: >>> On 10/10/2012 10:46 AM, Angel Ezquerra wrote: >>>> On Wed, Oct 10, 2012 at 2:25 PM, Christopher Felton >>>> <chr...@gm...> wrote: >>>>> <snip> >>>>>> >>>>>> >>>>>>>> Anyway, since this process seems easy to automate (I can't really >>>>>>>> tell, since I don't really understand it), the obvious question is why >>>>>>>> not make MyHDL itself automate it for us? That should put to rest the >>>>>>>> question of generating hierarchical VHDL or Verilog code which seems >>>>>>>> to crop up regularly on this list and on other online discussions >>>>>>>> about MyHDL! >>>>>>> >>>>>>> The obvious question is why someone interested in a >>>>>>> feature doesn't propose a MEP and a patch? >>>>>> >>>>>> That is a fair point. I am still "testing the waters" with MyHDL so to >>>>>> speak, so for now I am just raising the concerns that I come up with. >>>>>> >>>>>> I could try to write a MEP but first I'd like to see if there is some >>>>>> consensus that this could be a worthy idea (as I believe it is). Also, >>>>>> what would be the preferred way to indicate that a group of generators >>>>>> should be grouped into an entity and placed on their own file? >>>>>> >>>>>> For example, in the case that you described, imagine that you had had >>>>>> a magic wand that let you modify MyHDL in a way that you could have >>>>>> avoided all the manual work involved in solving your problem. How >>>>>> would you have liked to be able to tell MyHDL that you wanted to place >>>>>> "submodule" on its own file? >>>>>> >>>>>> Contributing a patch is another matter though. I am quite busy >>>>>> contributing to TortoiseHg at the moment and I don't know how complex >>>>>> the MyHDL code base is. I don't know that I'd have the time to dig >>>>>> deep enough into it to contribute such a patch. >>>>>> >>>>> >>>>> I am having a hard time following you. At one point >>>>> you comment >>>>> >>>>> "since this process seems easy to automate ..." >>>>> >>>>> then you comment >>>>> >>>>> "... the amount of steps would be great" >>>>> (implying difficulty) >>>>> >>>>> But if it is easy to automate why would we be concerned >>>>> with the number of steps? >>>> >>>> I should have been more clear: >>>> - The process "seems easy to automate" according to what you said. >>>> - But it _currently_ requires a great number of steps since it must be >>>> performed _manually_ (which does not necessarily mean that it would be >>>> hard, just tiresome). >>>> >>>> That is, currently MyHDL does not provide a way to make this without >>>> too much effort, but apparently (from what you said) it should be >>>> possible to make it automatic. >>>> >>>>> I also get confused if you are only interested in an >>>>> existing solution or you are willing to experiment and >>>>> be part of a development. This conversation seems to >>>>> bounce back and forth between wanting a working solution >>>>> and "testing the waters". I am never sure which I am >>>>> replying to. Given the comments above, I assume you >>>>> are mainly interested in existing and working solutions. >>>>> >>>>> Maintaining hierarchy during conversion is a reasonable >>>>> feature request. But the priority of the feature? And >>>>> the best path forward? I think it is safe to say, given >>>>> the resources available this feature will not be added >>>>> any time soon. I think you are simply trying to stimulate >>>>> conversation and ideas (which is good!). But I don't believe >>>>> anyone has the bandwidth to experiment and implement the >>>>> feature. >>>> >>>> I'm mostly interested on working solutions, but since it seems there >>>> are none (at least not experimental ones), I want to spur the >>>> conversation some and show that there are people (at least one! :-) >>>> interested on this feature. >>>> >>>> As for contributing I have a few small patches ready that I will send >>>> to the list shortly. These address some of small issues regarding VHDL >>>> code generation that I identified on another email. >>>> >>>> Cheers, >>>> >>>> Angel >>>> >>> >>> Angel, >>> >>> Make sure you review the "Guide for Developers": >>> http://www.myhdl.org/doku.php/dev:patches >>> >>> Jan D. has put together a comprehensive guide for contributing >>> to the project. >>> >>> Also note, Jan D. has the final say on all bundles submitted. >>> >>> Thanks for interest in contributing! >>> >>> Regards, >>> Chris >> >> OK, I did not know about that document. Sorry. >> >> Apparently it seems Jan prefers to receive bundles directly on his >> email address. I sent a patch series to the list because that is the >> way things are done on the tortoisehg and on the mercurial mailing >> list itself. The document seems to suggest that it is ok to send >> patches to the list for discussion though, so I guess what I did is >> kind of ok. >> >> Cheers, >> >> Angel >> > > I usually send patches/bundles directly to the mailing-list > (good or bad). The issue can be if it is large for some > reason. I don't believe it is bad to send patches to the > mailing-list. > > .chris OK, I will not need to resend them then :-) I tried to run the tests on my windows PC. The core tests run fine but I have trouble running the VHDL conversion tests (which are the most interesting ones for my patches). I was able to run the VHDL conversion tests, but I got 5 passes and 40 failures _without_ my patches. With my patches I get the same result. This is the output of running py.test on the myhdl\test\conversion\toVHDL folder: $ /c/Python27/Scripts/py.test ============================= test session starts ============================== platform win32 -- Python 2.7.2 -- pytest-2.2.4 collecting ... collected 45 items test_custom.py FFFF.. test_enum.py F test_loops.py . test_newcustom.py FFFF.. test_ops.py FFFFFFFFFFFFFF test_signed.py FFFFFFFFFFFFFFFFF =================================== FAILURES =================================== __________________________________ testIncRef __________________________________ def testIncRef(): > assert conversion.verify(customBench, incRef) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, incRef) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_custom.py:248: AssertionError ------------------------------- Captured stderr -------------------------------- customBench.vhd:59:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:63:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed ___________________________________ testInc ____________________________________ def testInc(): > assert conversion.verify(customBench, inc) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, inc) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_custom.py:251: AssertionError ------------------------------- Captured stderr -------------------------------- customBench.vhd:59:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:63:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed ___________________________________ testInc2 ___________________________________ def testInc2(): > assert conversion.verify(customBench, inc2) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, inc2) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_custom.py:254: AssertionError ------------------------------- Captured stderr -------------------------------- ** ToVHDLWarning: Signal is driven but not read: inc_inst_nextCount customBench.vhd:64:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:68:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed ___________________________________ testInc3 ___________________________________ def testInc3(): > assert conversion.verify(customBench, inc3) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, inc3) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_custom.py:257: AssertionError ------------------------------- Captured stderr -------------------------------- ** ToVHDLWarning: Signal is driven but not read: inc_inst_inc2_inst_nextCount customBench.vhd:64:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:68:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed __________________________________ test_enum ___________________________________ def test_enum(): > assert conversion.verify(bench_enum) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(bench_enum) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_enum.py:65: AssertionError ------------------------------- Captured stderr -------------------------------- error: cannot find entity or configuration bench_enum_ghdl Conversion verification failed __________________________________ testIncRef __________________________________ def testIncRef(): > assert conversion.verify(customBench, incRef) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, incRef) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_newcustom.py:248: AssertionError ------------------------------- Captured stderr -------------------------------- customBench.vhd:59:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:63:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed ___________________________________ testInc ____________________________________ def testInc(): > assert conversion.verify(customBench, inc) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, inc) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_newcustom.py:251: AssertionError ------------------------------- Captured stderr -------------------------------- customBench.vhd:59:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:63:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed ___________________________________ testInc2 ___________________________________ def testInc2(): > assert conversion.verify(customBench, inc2) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, inc2) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_newcustom.py:254: AssertionError ------------------------------- Captured stderr -------------------------------- customBench.vhd:64:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:68:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed ___________________________________ testInc3 ___________________________________ def testInc3(): > assert conversion.verify(customBench, inc3) == 0 E assert 1 == 0 E + where 1 = <myhdl.conversion._verify._VerificationClass object at 0x02451830>(customBench, inc3) E + where <myhdl.conversion._verify._VerificationClass object at 0x02451830> = conversion.verify test_newcustom.py:257: AssertionError ------------------------------- Captured stderr -------------------------------- customBench.vhd:64:14:warning: universal integer bound must be numeric literal or attribute customBench.vhd:68:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration custombench_ghdl Conversion verification failed ________________________________ testBinary[0] _________________________________ m = 4, n = 4 def checkBinary(m, n): > assert verify(binaryBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, 4, 4) test_ops.py:172: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:92:14:warning: universal integer bound must be numeric literal or attribute binaryBench.vhd:131:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed ________________________________ testBinary[1] _________________________________ m = 5, n = 3 def checkBinary(m, n): > assert verify(binaryBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, 5, 3) test_ops.py:172: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:92:14:warning: universal integer bound must be numeric literal or attribute binaryBench.vhd:115:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed ________________________________ testBinary[2] _________________________________ m = 2, n = 6 def checkBinary(m, n): > assert verify(binaryBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, 2, 6) test_ops.py:172: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:92:14:warning: universal integer bound must be numeric literal or attribute binaryBench.vhd:107:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed ________________________________ testBinary[3] _________________________________ m = 8, n = 7 def checkBinary(m, n): > assert verify(binaryBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, 8, 7) test_ops.py:172: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:92:14:warning: universal integer bound must be numeric literal or attribute binaryBench.vhd:355:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testMultiOps[0] ________________________________ m = 4, n = 4, p = 4 def checkMultiOps(m, n, p): > assert verify(multiBench, m, n, p) == 0 E assert 1 == 0 E + where 1 = verify(multiBench, 4, 4, 4) test_ops.py:264: AssertionError ------------------------------- Captured stderr -------------------------------- multiBench.vhd:45:14:warning: universal integer bound must be numeric literal or attribute multiBench.vhd:99:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration multibench_ghdl Conversion verification failed _______________________________ testMultiOps[1] ________________________________ m = 5, n = 3, p = 2 def checkMultiOps(m, n, p): > assert verify(multiBench, m, n, p) == 0 E assert 1 == 0 E + where 1 = verify(multiBench, 5, 3, 2) test_ops.py:264: AssertionError ------------------------------- Captured stderr -------------------------------- multiBench.vhd:45:14:warning: universal integer bound must be numeric literal or attribute multiBench.vhd:63:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration multibench_ghdl Conversion verification failed _______________________________ testMultiOps[2] ________________________________ m = 3, n = 4, p = 6 def checkMultiOps(m, n, p): > assert verify(multiBench, m, n, p) == 0 E assert 1 == 0 E + where 1 = verify(multiBench, 3, 4, 6) test_ops.py:264: AssertionError ------------------------------- Captured stderr -------------------------------- multiBench.vhd:45:14:warning: universal integer bound must be numeric literal or attribute multiBench.vhd:75:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration multibench_ghdl Conversion verification failed _______________________________ testMultiOps[3] ________________________________ m = 3, n = 7, p = 4 def checkMultiOps(m, n, p): > assert verify(multiBench, m, n, p) == 0 E assert 1 == 0 E + where 1 = verify(multiBench, 3, 7, 4) test_ops.py:264: AssertionError ------------------------------- Captured stderr -------------------------------- multiBench.vhd:45:14:warning: universal integer bound must be numeric literal or attribute multiBench.vhd:75:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration multibench_ghdl Conversion verification failed _______________________________ testUnaryOps[0] ________________________________ m = 4 def checkUnaryOps(m): > assert verify(unaryBench, m) == 0 E assert 1 == 0 E + where 1 = verify(unaryBench, 4) test_ops.py:326: AssertionError ------------------------------- Captured stderr -------------------------------- unaryBench.vhd:37:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration unarybench_ghdl Conversion verification failed _______________________________ testUnaryOps[1] ________________________________ m = 7 def checkUnaryOps(m): > assert verify(unaryBench, m) == 0 E assert 1 == 0 E + where 1 = verify(unaryBench, 7) test_ops.py:326: AssertionError ------------------------------- Captured stderr -------------------------------- unaryBench.vhd:37:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration unarybench_ghdl Conversion verification failed ________________________________ testAugmOps[0] ________________________________ m = 4, n = 4 def checkAugmOps(m, n): > assert verify(augmBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, 4, 4) test_ops.py:466: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:98:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[1] ________________________________ m = 5, n = 3 def checkAugmOps(m, n): > assert verify(augmBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, 5, 3) test_ops.py:466: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:98:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[2] ________________________________ m = 2, n = 6 def checkAugmOps(m, n): > assert verify(augmBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, 2, 6) test_ops.py:466: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:98:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[3] ________________________________ m = 8, n = 7 def checkAugmOps(m, n): > assert verify(augmBench, m, n) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, 8, 7) test_ops.py:466: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:98:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed _______________________________ testBinaryOps[0] _______________________________ Ll = -254, Ml = 236, Lr = 0, Mr = 4 def checkBinaryOps( Ll, Ml, Lr, Mr): > assert verify(binaryBench, Ll, Ml, Lr, Mr ) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, -254, 236, 0, 4) test_signed.py:188: AssertionError ------------------------------- Captured stderr -------------------------------- ** ToVHDLWarning: Signal is not driven: RightShift binaryBench.vhd:69:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testBinaryOps[1] _______________________________ Ll = -128, Ml = 128, Lr = -128, Mr = 128 def checkBinaryOps( Ll, Ml, Lr, Mr): > assert verify(binaryBench, Ll, Ml, Lr, Mr ) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, -128, 128, -128, 128) test_signed.py:188: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:69:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testBinaryOps[2] _______________________________ Ll = -53, Ml = 25, Lr = -23, Mr = 123 def checkBinaryOps( Ll, Ml, Lr, Mr): > assert verify(binaryBench, Ll, Ml, Lr, Mr ) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, -53, 25, -23, 123) test_signed.py:188: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:69:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testBinaryOps[3] _______________________________ Ll = -23, Ml = 145, Lr = -66, Mr = 12 def checkBinaryOps( Ll, Ml, Lr, Mr): > assert verify(binaryBench, Ll, Ml, Lr, Mr ) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, -23, 145, -66, 12) test_signed.py:188: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:69:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testBinaryOps[4] _______________________________ Ll = 23, Ml = 34, Lr = -34, Mr = -16 def checkBinaryOps( Ll, Ml, Lr, Mr): > assert verify(binaryBench, Ll, Ml, Lr, Mr ) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, 23, 34, -34, -16) test_signed.py:188: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:69:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testBinaryOps[5] _______________________________ Ll = -54, Ml = -20, Lr = 45, Mr = 73 def checkBinaryOps( Ll, Ml, Lr, Mr): > assert verify(binaryBench, Ll, Ml, Lr, Mr ) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, -54, -20, 45, 73) test_signed.py:188: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:69:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testBinaryOps[6] _______________________________ Ll = -25, Ml = -12, Lr = -123, Mr = -66 def checkBinaryOps( Ll, Ml, Lr, Mr): > assert verify(binaryBench, Ll, Ml, Lr, Mr ) == 0 E assert 1 == 0 E + where 1 = verify(binaryBench, -25, -12, -123, -66) test_signed.py:188: AssertionError ------------------------------- Captured stderr -------------------------------- binaryBench.vhd:69:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration binarybench_ghdl Conversion verification failed _______________________________ testUnaryOps[0] ________________________________ m = 4 def checkUnaryOps(m): > assert verify(unaryBench, m) == 0 E assert 1 == 0 E + where 1 = verify(unaryBench, 4) test_signed.py:266: AssertionError ------------------------------- Captured stderr -------------------------------- unaryBench.vhd:37:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration unarybench_ghdl Conversion verification failed _______________________________ testUnaryOps[1] ________________________________ m = 7 def checkUnaryOps(m): > assert verify(unaryBench, m) == 0 E assert 1 == 0 E + where 1 = verify(unaryBench, 7) test_signed.py:266: AssertionError ------------------------------- Captured stderr -------------------------------- unaryBench.vhd:37:14:warning: universal integer bound must be numeric literal or attribute error: cannot find entity or configuration unarybench_ghdl Conversion verification failed ________________________________ testAugmOps[0] ________________________________ Ll = -254, Ml = 236, Lr = 0, Mr = 4 def checkAugmOps( Ll, Ml, Lr, Mr): > assert verify(augmBench, Ll, Ml, Lr, Mr) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, -254, 236, 0, 4) test_signed.py:412: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:60:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[1] ________________________________ Ll = -128, Ml = 128, Lr = -128, Mr = 128 def checkAugmOps( Ll, Ml, Lr, Mr): > assert verify(augmBench, Ll, Ml, Lr, Mr) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, -128, 128, -128, 128) test_signed.py:412: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:60:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[2] ________________________________ Ll = -53, Ml = 25, Lr = -23, Mr = 123 def checkAugmOps( Ll, Ml, Lr, Mr): > assert verify(augmBench, Ll, Ml, Lr, Mr) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, -53, 25, -23, 123) test_signed.py:412: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:60:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[3] ________________________________ Ll = -23, Ml = 145, Lr = -66, Mr = 12 def checkAugmOps( Ll, Ml, Lr, Mr): > assert verify(augmBench, Ll, Ml, Lr, Mr) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, -23, 145, -66, 12) test_signed.py:412: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:60:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[4] ________________________________ Ll = 23, Ml = 34, Lr = -34, Mr = -16 def checkAugmOps( Ll, Ml, Lr, Mr): > assert verify(augmBench, Ll, Ml, Lr, Mr) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, 23, 34, -34, -16) test_signed.py:412: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:60:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[5] ________________________________ Ll = -54, Ml = -20, Lr = 45, Mr = 73 def checkAugmOps( Ll, Ml, Lr, Mr): > assert verify(augmBench, Ll, Ml, Lr, Mr) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, -54, -20, 45, 73) test_signed.py:412: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:60:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed ________________________________ testAugmOps[6] ________________________________ Ll = -25, Ml = -12, Lr = -123, Mr = -66 def checkAugmOps( Ll, Ml, Lr, Mr): > assert verify(augmBench, Ll, Ml, Lr, Mr) == 0 E assert 1 == 0 E + where 1 = verify(augmBench, -25, -12, -123, -66) test_signed.py:412: AssertionError ------------------------------- Captured stderr -------------------------------- augmBench.vhd:60:14:warning: universal integer bound must be numeric literal or attribute <class 'myhdl.StopSimulation'>: No more events error: cannot find entity or configuration augmbench_ghdl Conversion verification failed _______________________________ testExpressions ________________________________ def testExpressions(): > assert verify(expressionsBench) == 0 E assert 1 == 0 E + where 1 = verify(expressionsBench) test_signed.py:503: AssertionError ------------------------------- Captured stderr -------------------------------- error: cannot find entity or configuration expressionsbench_ghdl Conversion verification failed ===================== 40 failed, 5 passed in 16.95 seconds ===================== Cheers, Angel |
|
From: Christopher F. <chr...@gm...> - 2012-10-10 20:05:12
|
<snip> > > I was able to run the VHDL conversion tests, but I got 5 passes and 40 > failures _without_ my patches. With my patches I get the same result. > This is the output of running py.test on the > myhdl\test\conversion\toVHDL folder: > > $ /c/Python27/Scripts/py.test > ============================= test session starts ============================== > platform win32 -- Python 2.7.2 -- pytest-2.2.4 > collecting ... collected 45 items > > test_custom.py FFFF.. > test_enum.py F > test_loops.py . > test_newcustom.py FFFF.. > test_ops.py FFFFFFFFFFFFFF > test_signed.py FFFFFFFFFFFFFFFFF > > =================================== FAILURES =================================== I haven't run the VHDL conversion tests on WIN32. Do you have GHDL installed? .chris |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X