prims: do some cleanups

[thoughtpolice]

• Delete some primitives like GreyCntr. These aren't used anywhere.
• Remove some ifdef workarounds for Icarus Verilog that no longer apply, I believe. (Icarus v11.0 seems to simulate the included generate blocks fine, as far as I can tell?)
• Consolidate most of the Vivado primitives with the generic RTL primitives. These are all just copy/paste identical files, except with a few verilog annotations for clock buffers/RAM primitives. Users can now instead just define VIVADO in their synthesis tool (hopefully, uh, vivado) in order to enable these.

Point 3 might be the most controversial, but I think this is significantly better than requiring the search paths to be amended for a tool or different primitives selected transparently. It would be even better if vendor tools would define some macros by default for auto-detection, but, alas...

I also plan on doing the same thing for Quartus too, but I wanted to get the thrust of all this out there first off.

This is all done in preparation for a fix for #139.

[thoughtpolice]

Re: point 3 — there is an odd discrepancy I discovered in the GatedClock primitive where it behaves completely differently on Vivado. I don't know what should be done about this, but it seems these are in conflict?

--- Verilog/GatedClock.v        2021-01-16 02:42:30.358357579 -0600
+++ Verilog.Vivado/GatedClock.v 2021-01-15 23:41:08.262363786 -0600
@@ -17,7 +17,7 @@
 // To avoid glitches, CLK_GATE_OUT only changes  when CLK_IN is low.
 // CLK_GATE_OUT follows CLK_GATE_IN in the same cycle, but COND is first
 // registered, thus delaying the gate condition by one cycle.
-// In this model, the oscillator CLK_OUT stop when the CLK_GATE_IN or
+// In this model, the oscillator CLK_OUT does *not* stop when the CLK_GATE_IN or
 // COND are deasserted.
 module GatedClock(
                  // ports for the internal register
@@ -54,7 +54,7 @@

    assign COND_OUT = COND_reg;

-   assign CLK_OUT = CLK_IN & new_gate ;
+   assign CLK_OUT = CLK_IN; // & new_gate ;
    assign CLK_GATE_OUT = new_gate ;

    // Use latch to avoid glitches
@@ -90,4 +90,3 @@
 `endif // BSV_NO_INITIAL_BLOCKS

 endmodule // GatedClock
-

[quark17]

Thanks for contributing cleanups! I haven't yet had a close look, but I think it's probably good to use ifdefs when the only difference is an attribute. I've asked @czeck to have a look, too, to have a second (and better) set of eyes on the Verilog files. But I did want to reply to your comment about GatedClock: The difference in these files is not a problem.

For gated clocks in a BSC design, BSC expects an oscillator wire and a gate wire, but BSC is agnostic about whether the oscillator still oscillates when the gate is de-asserted. BSC does not use the wires in a way that it matters. This allows the user to decide what is better for their synthesis (or simulation) target. So it's OK for the generic and Vivado versions to differ -- although we can certainly revisit the decision. (Maybe @czeck can say something about the original choices that went into it.)

[czeck]

Hi Austin, Thanks for the PR. They look good. I saw that you merged verilog.Vivado and Verilog.quartus. How did you handle the differences in BRAM2.v I did not follow those differences. WRT to Verilog/GatedClock.v, the bsc model disables actions when gate is low, regardless of clock edge. IIRC, Vivado (circa 2010) did not like having a clock oscillator gated. In their architecture, there are clock regions each with dedicated clock routing, so throwing in a gate was not allowed. This led to the difference in the GatedClock module. I do not have a means to test this. Which tools have you tried this verilog? Best, Ed.

…

On Wed, Jan 20, 2021 at 12:53 AM Julie Schwartz ***@***.***> wrote: Thanks for contributing cleanups! I haven't yet had a close look, but I think it's probably good to use ifdefs when the only difference is an attribute. I've asked @czeck <https://github.com/czeck> to have a look, too, to have a second (and better) set of eyes on the Verilog files. But I did want to reply to your comment about GatedClock: The difference in these files is not a problem. For gated clocks in a BSC design, BSC expects an oscillator wire and a gate wire, but BSC is agnostic about whether the oscillator still oscillates when the gate is de-asserted. BSC does not use the wires in a way that it matters. This allows the user to decide what is better for their synthesis (or simulation) target. So it's OK for the generic and Vivado versions to differ -- although we can certainly revisit the decision. (Maybe @czeck <https://github.com/czeck> can say something about the original choices that went into it.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB24HQDD36Q3RCDQ5ZYTAN3S2ZVU3ANCNFSM4WFBTIMQ> .

[quark17]

Thank you again for these cleanups. As you can see, I have merged the first two commits, leaving the third. (You may want to rebase this PR on the head, with just that commit?)

When a version of a module differs just by an attribute, having them in one file with an ifdef around the attribute makes sense just to avoid duplication that can get out of sync. But I worry that it may be inevitable that different tools may need drastically different modules. (For example, the Quartus versions of BRAM modules look quite different -- but they were created with old versions of Quartus and the situation may be improved now.)

I want to understand if the idea here is that all versions of a primitive would be defined in the same file. That is, if the Quartus version is wildly different, then there may just be a second module..endmodule block in the file, and ifdef directives would pick the appropriate one? The more I mull it over, the more I think I could get behind that idea.