myhdl-list

[myhdl-list] code generation compatibility with old Verilog/VHDL

[<G.A...@gm...>]

Hi myHdlers,

I'm using an old cypress CPLD: CY37000 chip and so I'm using an old  
synthesis tool: Warp 6.3 (2002). I'm seeing some compile errors in both the  
generated Verilog and VHDL code and I'm assuming that they have to do with  
using a very old synthesis tool.

In the Verilog code, I was able to make small changes to get my design to  
synthesize, until I hit a problem that Warp 6.3 does not support signed  
regs... *sigh*. I'm guessing this is rare enough that no one is interested  
in putting automatic generation of signed logic in the myHdl->Verilog  
generator?

So I noticed that Warp 6.3 does support signed logic in VHDL, so Great! I  
can use the cool new 0.6 feature! Well...no. There are errors in the VHDL  
synthesis also, and I don't know VHDL at all...

Is there any interest in supporting old versions? Some of the problems seem  
to be simple syntax changes, or optional libraries (for example, in  
vhdl "use std.textio.all" (no textio library found).

BTW, As a quick "fix" it might be nice to put the language version in the  
comment so that people know what the generated code is targeted to.

Finally, just as a shot in the dark, does anyone know of a more modern free  
synthesis tool that can target CY37256P160-83AC?

Regards,
Andrew

Re: [myhdl-list] code generation compatibility with old Verilog/VHDL

[Jan D. <ja...@ja...>]

G.A...@gm... wrote:
> Hi myHdlers,
> 
> I'm using an old cypress CPLD: CY37000 chip and so I'm using an old 
> synthesis tool: Warp 6.3 (2002). I'm seeing some compile errors in both 
> the generated Verilog and VHDL code and I'm assuming that they have to 
> do with using a very old synthesis tool.

Probably, but not necessarily. MyHDL can convert much more than can
reasonably be synthesized. For better info, you'd have to tell us
more about the kind of compile errors you get.

There's no escape: you have to understand what Verilog/VHDL your
synthesis tool understands.

With MyHDL, there's an additional complication: you have to understand
how get supported HDL code out of the convertor. With a little practice,
this shouldn't be hard, as there is a pretty close mapping from
the MyHDL input to the HDL output.

> In the Verilog code, I was able to make small changes to get my design 
> to synthesize, until I hit a problem that Warp 6.3 does not support 
> signed regs... *sigh*. I'm guessing this is rare enough that no one is 
> interested in putting automatic generation of signed logic in the 
> myHdl->Verilog generator?

Indeed. Your option here is to do what Verilog designers had to do for a
very long time (until the language had signed): emulate signed behavior
manually using unsigneds only.

> So I noticed that Warp 6.3 does support signed logic in VHDL, so Great! 
> I can use the cool new 0.6 feature! Well...no. There are errors in the 
> VHDL synthesis also, and I don't know VHDL at all...
> 
> Is there any interest in supporting old versions? Some of the problems 
> seem to be simple syntax changes, or optional libraries (for example, in 
> vhdl "use std.textio.all" (no textio library found).

std.textio is actually only required for printing. I guess I could
make the convertor more intelligent by only including it when needed.
On the other hand, it's a standard package that any VHDL tool should
know about.

> BTW, As a quick "fix" it might be nice to put the language version in 
> the comment so that people know what the generated code is targeted to.

I guess you mean the Verilog or VHDL version? At this moment this is
just based on an estimated conservative common ground.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] code generation compatibility with old Verilog/VHDL

[Andrew S. <g.a...@gm...>]

Thanks, for your reply, Jan!

I think that there may be a bug in the intbv bounds checking logic.
Maybe because Python is a little too clever when you do two's
complement by hand?
>>> print (~5)+1
-5

So I can't really do two's complement by hand to create negative
numbers... see inline for more details.  Also, I've included a couple
of the syntax errors that I'm getting in the verilog and vhdl
compilation.  But I'd like to emphasize that if the problems are
caused by the fact that my synthesis tool is old (2002) then pls don't
fix just on my account! :-)  Instead let's think about whether
compatibility with old systems is a priority for myHdl.  It may very
well be.  For example Linux has a pretty thriving community of people
putting it on old junker computers...

Specific responses below:

Thanks for your help,
Andrew

On Tue, Dec 23, 2008 at 6:09 AM, Jan Decaluwe <ja...@ja...> wrote:
> G.A...@gm... wrote:
>> Hi myHdlers,
>>
>> I'm using an old cypress CPLD: CY37000 chip and so I'm using an old
>> synthesis tool: Warp 6.3 (2002). I'm seeing some compile errors in both
>> the generated Verilog and VHDL code and I'm assuming that they have to
>> do with using a very old synthesis tool.
>
> Probably, but not necessarily. MyHDL can convert much more than can
> reasonably be synthesized. For better info, you'd have to tell us
> more about the kind of compile errors you get.

Hmm, I don't think that its that kind of error.  For example the latch
code from the doc:

def latch(reset, d, q):
    @always_comb
    def logic():
        if reset == 0:
            q.next = d

    return logic

Instantiated like this:

latch_circuit = latch(reset,clk,latchout)

Gives this:

always @(reset, clk) begin: _hwtest_latch_circuit_logic
    if ((reset == 0)) begin
        latchout <= clk;
    end
end

The synthesis tool does not like the comma in @(reset,clk).  But it
works if I use "or":

always @(reset or clk) begin:


>
> There's no escape: you have to understand what Verilog/VHDL your
> synthesis tool understands.

I hope this will not always be true -- for example most C programmers
would be hard pressed to understand the generated assembly code.

>
> With MyHDL, there's an additional complication: you have to understand
> how get supported HDL code out of the convertor. With a little practice,
> this shouldn't be hard, as there is a pretty close mapping from
> the MyHDL input to the HDL output.

Yes, its great!  I'm not having much trouble reading the verilog output.

>
>> In the Verilog code, I was able to make small changes to get my design
>> to synthesize, until I hit a problem that Warp 6.3 does not support
>> signed regs... *sigh*. I'm guessing this is rare enough that no one is
>> interested in putting automatic generation of signed logic in the
>> myHdl->Verilog generator?
>
> Indeed. Your option here is to do what Verilog designers had to do for a
> very long time (until the language had signed): emulate signed behavior
> manually using unsigneds only.

I think that there may be a bug here...  It still triggers the
negative assertion in myhdl.

Specifically in myhdl:

cPos = Signal(intbv(0)[32:])
deltaPos = Signal(intbv(0)[32:])
nextPos = Signal(intbv(0)[32:])

sometime later:
print cPos
print nextPos
deltaPos.next = (~(cPos-nextPos))+1

output:

199
0
> /me/fpga/myhdlcode/varstep.py(51)step()
-> deltaPos.next = (~(cPos-nextPos))+1
(Pdb) c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "varstep.py", line 150, in <module>
    simulate(10 * 1000)
  File "varstep.py", line 148, in simulate
    sim.run(timesteps)
  File "/me/fpga/myhdl/repo/myhdl/_Simulation.py", line 132, in run
    waiter.next(waiters, actives, exc)
  File "/me/fpga/myhdl/repo/myhdl/_Waiter.py", line 137, in next
    clause = self.generator.next()
  File "/me/fpga/myhdl/repo/myhdl/_always.py", line 105, in genfunc
    func()
  File "varstep.py", line 51, in step
    deltaPos.next = (~(cPos-nextPos))+1
  File "/me/fpga/myhdl/repo/myhdl/_Signal.py", line 194, in _set_next
    self._setNextVal(val)
  File "/me/fpga/myhdl/repo/myhdl/_Signal.py", line 253, in _setNextIntbv
    self._next._checkBounds()
  File "/me/fpga/myhdl/repo/myhdl/_intbv.py", line 85, in _checkBounds
    (self._val, self._min))
ValueError: intbv value -199 < minimum 0
>>>

>
>> So I noticed that Warp 6.3 does support signed logic in VHDL, so Great!
>> I can use the cool new 0.6 feature! Well...no. There are errors in the
>> VHDL synthesis also, and I don't know VHDL at all...
>>
>> Is there any interest in supporting old versions? Some of the problems
>> seem to be simple syntax changes, or optional libraries (for example, in
>> vhdl "use std.textio.all" (no textio library found).
>
> std.textio is actually only required for printing. I guess I could
> make the convertor more intelligent by only including it when needed.
> On the other hand, it's a standard package that any VHDL tool should
> know about.
>

One other issue was that in the generated code pck_myhdl_06dev10 there's a line:

attribute enum_encoding: string;

This line causes the error:
pck_myhdl_06dev10.vhd (line 11, col 29):  (E56) Expected OF, but got :

Next, my generated code looks like this:

-- File: bresStepTest.vhd
-- Generated by MyHDL 0.6dev10
-- Date: Mon Dec 22 22:50:13 2008

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
--use std.textio.all;

use work.pck_myhdl_06dev10.all;

entity bresStepTest is
    port (
        clk: in std_logic;
        reset: in std_logic;
        osc: in std_logic;
        oscCount: inout unsigned(31 downto 0);
        coils: inout unsigned(3 downto 0);
        stepType: in std_logic
    );
end entity bresStepTest;

architecture MyHDL of bresStepTest is

signal nextPos: signed (31 downto 0);
signal nextTime: signed (31 downto 0);
signal loaded: std_logic;
signal testTime: signed (31 downto 0);
signal bresCircuit_timeLeft: signed (31 downto 0);
signal bresCircuit_deltaTime: signed (31 downto 0);
signal bresCircuit_deltaPos: signed (31 downto 0);
signal bresCircuit_cPos: signed (31 downto 0);
signal bresCircuit_curCtr: signed (31 downto 0);

begin


BRESSTEPTEST_DRIVEMOTORCMDS: process (clk) is
begin

And I get an error:
main.vhd (line 38, col 46):  (E10) Syntax error at/before reserved symbol 'is'.

Re: [myhdl-list] code generation compatibility with old Verilog/VHDL

[Jan D. <ja...@ja...>]

Andrew Stone wrote:
> Thanks, for your reply, Jan!
> 
> I think that there may be a bug in the intbv bounds checking logic.
> Maybe because Python is a little too clever when you do two's
> complement by hand?
>>>> print (~5)+1
> -5
> 
> So I can't really do two's complement by hand to create negative
> numbers... see inline for more details. 

That may be right. Bit inversion on constrained intbv's works
differently though - if min>0, it will return positive numbers.
But even then, thinking about it, it may be much more complicated
than in Verilog to emulate signed behavior with only "unsigned"
intbv's. MyHDL strictly checks bounds, Verilog typically just
does operations compatible with 2's complement arithmetic, even
with only positive numbers.

 > also, I've included a couple
> of the syntax errors that I'm getting in the verilog and vhdl
> compilation.  But I'd like to emphasize that if the problems are
> caused by the fact that my synthesis tool is old (2002) then pls don't
> fix just on my account! :-)  Instead let's think about whether
> compatibility with old systems is a priority for myHdl.  It may very
> well be.  For example Linux has a pretty thriving community of people
> putting it on old junker computers...

Very old and limited tools indeed seem to be the culprit, see further.
I would hesitiate very much to include this in the main MyHDL code
(why support abondoned tools?). However, it seems easy to fix your
issues locally by a few patches. (You could do this in a local
mercurial clone that still tracks future development.)


> Specific responses below:
> 
> Thanks for your help,
> Andrew



> The synthesis tool does not like the comma in @(reset,clk).  But it
> works if I use "or":

Verilog-2001.


>> There's no escape: you have to understand what Verilog/VHDL your
>> synthesis tool understands.
> 
> I hope this will not always be true -- for example most C programmers
> would be hard pressed to understand the generated assembly code.

Note that I wasn't talking about the synthesis tool output - that's
another subject. I was talking about the *input*.

I'm pretty sure it will stay like that for the following reason. It
would actually be pretty simple to design a HDL that could be
synthesized "completely". There have in fact be many attempts.
In fact people are still trying.

But all attempts have failed, and that should tell us something.
It tells us that such languages are too simple for serious
modelling and test benches. The kind of HDL that people want
is one that is very powerful for modeling/simulation in the first
place. Synthesis is just one thing that people want to do
with some of the models, and it naturally much more limited.
Note that software doesn't have this simulation / synthesis duality.

There is a reason why Verilog and VHDL are winners instead of the
myriad of implementation-centric attempts. MyHDL is happy to be
in the same camp.

> 
> One other issue was that in the generated code pck_myhdl_06dev10 there's a line:
> 
> attribute enum_encoding: string;
> 
> This line causes the error:
> pck_myhdl_06dev10.vhd (line 11, col 29):  (E56) Expected OF, but got :

Standard VHDL ...
This is only needed if you use enum types in MyHDL source code.

> 
> Next, my generated code looks like this:
> 
> -- File: bresStepTest.vhd
> -- Generated by MyHDL 0.6dev10
> -- Date: Mon Dec 22 22:50:13 2008
> 
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.numeric_std.all;
> --use std.textio.all;
> 
> use work.pck_myhdl_06dev10.all;
> 
> entity bresStepTest is
>     port (
>         clk: in std_logic;
>         reset: in std_logic;
>         osc: in std_logic;
>         oscCount: inout unsigned(31 downto 0);
>         coils: inout unsigned(3 downto 0);
>         stepType: in std_logic
>     );
> end entity bresStepTest;
> 
> architecture MyHDL of bresStepTest is
> 
> signal nextPos: signed (31 downto 0);
> signal nextTime: signed (31 downto 0);
> signal loaded: std_logic;
> signal testTime: signed (31 downto 0);
> signal bresCircuit_timeLeft: signed (31 downto 0);
> signal bresCircuit_deltaTime: signed (31 downto 0);
> signal bresCircuit_deltaPos: signed (31 downto 0);
> signal bresCircuit_cPos: signed (31 downto 0);
> signal bresCircuit_curCtr: signed (31 downto 0);
> 
> begin
> 
> 
> BRESSTEPTEST_DRIVEMOTORCMDS: process (clk) is
> begin
> 
> And I get an error:
> main.vhd (line 38, col 46):  (E10) Syntax error at/before reserved symbol 'is'.


Consistent support for "is" keyword was introduced in VHDL-93.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org