1
\$\begingroup\$

Today, I came across this problem on QuickSilicon's RTL Hackathon. It was to design an Endian converter.

The requirements were

  1. The output should be available in the same cycle
  2. The module should produce an output every cycle.
  3. All flip-flops, if any, should be triggered on the rising edge of the clock and resets should be asynchronous.

The only way this would work (i.e output is provided on the same cycle as the input is seen) if there are no flip-flops in the module.

module big_endian_converter #(
  parameter DATA_W = 32
)(
  input   wire              clk,
  input   wire              reset,

  input   wire [DATA_W-1:0] le_data_i,

  output  wire [DATA_W-1:0] be_data_o

);

  // Write your logic here
  logic [DATA_W-1:0] be_data;
  always_comb begin
        // convert endian
  end
 
  assign be_data_o = /* code for reset */;
    
endmodule

That would imply that the design is combinational and the clock signal is not really used. Is this possible for a signal in the module is not used? Can this unused signal still be useful? If yes, how can it be useful?

Is it common to include a clock input for non-sequential logic?

\$\endgroup\$
1
  • \$\begingroup\$ What do you mean by 'unused'? \$\endgroup\$ – Bruce Abbott Feb 13 at 17:34
2
\$\begingroup\$

The only way this would work (i.e output is provided on the same cycle as the input is seen) if there are no flip-flops in the module.

Well, there could be a flop triggered on the falling edge of the clock and if we split enough hairs it could be argued the output is still in the same cycle, just delayed a half cycle...

But from the module and input/output names it appears this is a little endian to big endian converter, which means it will contain no combinatorial logic at all, just wires. And even then, the wires are virtual since all this does is tell the compiler that some virtual input wires are connected to some virtual output wires, which makes them the same virtual wires. So this module doesn't contain any actual circuitry, just information to tell the compiler what you want to do with the signals.

\$\endgroup\$
3
  • \$\begingroup\$ May I know if it is justified to use a clock input here? Is it common? In the waveforms they are changing the inputs only on the rising edge of the clock. \$\endgroup\$ – Shashank V M Feb 14 at 4:30
  • \$\begingroup\$ You could have a rule that says every module needs a clock input even if it doesn't use it, but that's a bit weird. \$\endgroup\$ – bobflux Feb 14 at 8:38
  • \$\begingroup\$ Thanks @bobflux \$\endgroup\$ – Shashank V M Feb 14 at 9:31
0
\$\begingroup\$

Well, if you use the conventional 'clock is active on the rising edge' you are correct, you can only do a combinatory circuit (and propagation time will be your enemy).

However if you are going DDR (i.e. clocking on both rising and falling edge) technically you have your data 'in the same' clock period.

Would that be useful? probably no, since the following stage will latch the data on the next rising clock anyway, unless the whole system is DDR with alternate clock polarities.

Please note that with DDR I also intend dual 180° clocks in phase, that's more or less the same thing.

I'd say that this is not a normal design to be put on an FPGA, it borders asynchronous logic. As for the question, you clock input:

  • Is completely disconnected in a combinatory design
  • Drives the output register in a DDR logic

The definition 'is available on the same clock' IMHO is misleading, there will always be some propagation delay and the following stage will need it to be stable, even if only for a fraction of ps. We usually use synch logic to avoid issues like maximum path length and arrival phases of different signal, going combinatory opens a can of worms.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.