Not compatible with iVerilog about fx68k HOT 18 CLOSED

Hi, fx68k does not work with Verilator either. This would also be very helpful.

from fx68k.

SystemVerilog is NOT Verilog, although it encapsulates it.
I believe none of simulators support SystemVerilog (although some simulators support SystemVerilog for test benches).

from fx68k.

from fx68k.

All commercial simulators support synthesisable SV. FOSS need to be encouraged to support the SystemVerilog constructs which are synthesisable. SystemVerilog interfaces, multidimensional arrays in ports, increment/decrement and assign, loop variable declaration and increment/decrement are but a few of the features the RTL guys have embraced and are unlikely to give up.

from fx68k.

What are the error messages? Perhaps it is borderline legal code that can be restructured?

from fx68k.

Problem is not in FX68K. Problem is in iVerilog. Then why complain here?

from fx68k.

There were a couple of things only. The most cumbersome one is the use of interfaces. That’s not supported at all.
I have a branch of this in my fork where I can simulate with it. But it may contain bugs. I don’t have the test benches needed to verify it. That’s why I haven’t requested a pull.
You can see the changes I made at

https://github.com/jotego/fx68k/tree/fix2?files=1

from fx68k.

I could try and use Formality RTL->RTL and formally prove they are equivalent? You could try with FOSS SymbiYosis but it might not support SV Interfaces.

from fx68k.

So it's just fix of couple lines?

from fx68k.

Yes, if you could use formality to check it that would be great. I have no experience with formal checkers, though (shame on me).

If I recall correctly I had to remove some unique statements and the interfaces. It took me 1 hour maybe. I only use mine for simulation. For synthesis I use the original branch.

from fx68k.

FX68K uses the basic SV features only. There are no SV interfaces in FX68k. May be you mean "struct" types, and not interfaces.

Simulators should really support "struct". They are so useful for encapsulating signals passed between modules and also helps to make the code more self documented. The free (but of course, not open source) simulators provided by the main FPGA vendors do support struct types.

I have been told that Verilator does support struct types, but currently not correctly.

Removing UNIQUE, at least blindly, is dangerous and not a very good idea. The compiler might generate less efficient code using priority encoders that are really not needed. In some cases it might also make the simulator to produce a different behavior than synthesized code.

from fx68k.

Formality showed that Ijor master is identical to jotego fix2 (I had to update locally my fix2 with the latest commit on master "Some PC relative instructions had wrong FC encoding")

from fx68k.

Formally identical for the parameters as they are, I have forgotton how to make formality test all parameter combinations.

from fx68k.

I'm a little rusty on the subtleties of RTL->RTL formality scripts but this is a strong indicator the conversion is ok.

from fx68k.

Thank you very much for the formal comparison. I still made something wrong as I cannot synthesize with the modfied code:

Error (10166): SystemVerilog RTL Coding error at fx68kAlu.sv(780): always_comb construct does not infer purely combinational logic. File: /home/jtejada/github/jt_gng/modules/fx68k/fx68kAlu.sv Line: 780

And another question. Even if I made this exercise. Maybe this is not the shape you'd like for your core so it is not mergeable. I wonder if you prefer a different approach.

from fx68k.

Try uncommenting line 804

from fx68k.

If anyone is curious what Not Compared : Unread means. They are assignments which are made but never read which are not compared. Usually "unused" bits of a logic vector.

`
(Net ) r:/WORK/fx68k/excUnit/alu/rowDecoder/197_Undef_Inst.200_Undef_Inst.stype[0] (no reader)

(Net )  r:/WORK/fx68k/excUnit/alu/rowDecoder/197_Undef_Inst.200_Undef_Inst.stype[1]  (no reader)

(Net )  r:/WORK/fx68k/excUnit/alu/ccrCore[1]  (no reader)

(Net )  r:/WORK/fx68k/excUnit/alu/ccrCore[3]  (no reader)

(Net )  r:/WORK/fx68k/excUnit/alu/ccrCore[4]  (no reader)

(Net )  r:/WORK/fx68k/busControl/dataOe  (no reader)

(Net )  r:/WORK/fx68k/nanoLatch[23]  (no reader)

(Net )  r:/WORK/fx68k/nanoLatch[2]  (no reader)

(Net )  i:/WORK/fx68k/excUnit/alu/rowDecoder/197_Undef_Inst.200_Undef_Inst.stype[0]  (no reader)

(Net )  i:/WORK/fx68k/excUnit/alu/rowDecoder/197_Undef_Inst.200_Undef_Inst.stype[1]  (no reader)

(Net )  i:/WORK/fx68k/excUnit/alu/ccrCore[1]  (no reader)

(Net )  i:/WORK/fx68k/excUnit/alu/ccrCore[3]  (no reader)

(Net )  i:/WORK/fx68k/excUnit/alu/ccrCore[4]  (no reader)

(Net )  i:/WORK/fx68k/busControl/dataOe  (no reader)

(Net )  i:/WORK/fx68k/nanoLatch[23]  (no reader)

(Net )  i:/WORK/fx68k/nanoLatch[2]  (no reader)`

from fx68k.

We have made a fork that works both in synthesis and simulation (iverilog/verilator). It's here in branch fix6.

The edits are kind of ugly as we have just done the minimum required to make verilator work. So they are not worth a PR (I would reject it myself). Nonetheless, they solve the simulation problem.

We will still use the original version for synthesis.

from fx68k.