vhdl tips, how can I make this code parametric ?

[rstofer]

what do you think about a function approach ?

Code: [Select]

function mux_out
         (                         
           sel  : bus_mm_device_sel_t;
           pool : bus_mm_pool_out_t       
         )
         return bus_mm_out_t
is
  variable ans : bus_mm_out_t;
begin

  for i in 0 to bus_mm_device_n-1 loop
    if (sel(i) = '1') then
        ans := pool(0);
      end if;   
  end loop; 

  return ans;
end function;


The code probably should be a function or procedure because it is the kind of thing you might want in a library.  I'm no help with these choices.

But I'll bet you still get latches.  You just can't show that 'ans' is assigned an output for every possible input.  You can just assign a default value right after 'begin' (ans <= (others => '0'), assuming 'ans' is a vector).  What happens if sel() happens to be all 0's.  Sure, you know that can't happen but the synthesizer doesn't.

I really hope I'm firing on all thrusters!  Try my simple changes and see what happens.  If I'm all wrong, let me know!

As I understand latches, 'ans' will be assigned the value most recently 'latched' if  every 'if' statement is false.  But 'ans' WILL be assigned a value.  It's hardware...

I don't use the simulator and there is every chance that a simulation won't look like the value is latched.  I know that I have to be very careful to cover all output conditions where I actually run the hardware.

[legacy]

What happens if sel() happens to be all 0's.  Sure, you know that can't happen but the synthesizer doesn't.

ah, ok, now I have fully understood your point

[AndyC_772]

Not really on topic, but how can you see if code infers latches?
I usually have a process like:

Code: [Select]

process (clk) is
begin
    if rising_edge(clk) then
        <logic>
    end;

Which worked well enough for my purposes (but there are probably scenario's in which you want to do something else).

There's a difference between inferring a latch and inferring a clocked register bit. It's confusing that the term "latch" is ambiguous in this way.

If you have synchronous, clocked logic which doesn't update the state of an output under all conditions, then a D-type is inferred because it has to retain the state which was assigned to the output on a previous edge. This might be a small waste of logic, but it's not actually a problem.

So, for example, it's OK to write:

Code: [Select]

if rising_edge (clk) then
  if condition_a = '1' then
    output <= '1';
  else
    if condition_b = '1' then
      output <= '0';
    end if;
  end if;
end if;

This code sets the output high under condition 'a', and low under condition 'b'. If neither condition is true, then the output stays at its previous value, and a D-type is therefore needed to keep a record of what that value should be.

The problem comes if your logic isn't synchronous:

Code: [Select]

  if condition_a = '1' then
    output <= '1';
  else
    if condition_b = '1' then
      output <= '0';
    end if;
  end if;

This code is, of course, functionally similar, but it can't use a D-type because there's no clock. It still needs to maintain the value of the output during any times when both conditions are 0, and that infers a latch.

[legacy]

The problem comes if your logic isn't synchronous

that's the reason why I am doing everything synchronous, including the ALU modules
in the theory I could even rewrite the bus multiplexer to be synchronous
and it will cost an extra clock tick through the current cpu's data-path
 

[legacy]

ans <= (others => '0'), assuming 'ans' is a vector

it's an array of record (structured signals)

Code: [Select]

  type bus_mm_out_t is
  record
    data         : bus_mm_data_t;
    device_sel   : bus_mm_device_sel_t;
...
  end record;

bus_mm_data_t is a vector, with a size of 32bit

Code: [Select]

  type bus_mm_pool_out_t     is array (0 to bus_mm_device_n-1) of bus_mm_out_t;

this type represents the whole backplane as a collection of devices (excluding their physical signals, which are handled and propagated through another dedicated record-type)

Code: [Select]

-- [CPU] ==== core_bus ==== [adapter] ==== bus_mm
--
-- bus_mm
--    +-- mux
--          +-- device0
--          +-- device1
--               ...
--          +-- devicen-1

the core_bus is a simple cpu_bus which doesn't care about misalignment, dtack, wait-cycles, and other details, it simply passes the IO_request{rw,size,data,address} to the adapter which uses the multiplexer in order to *select* the proper device (16 devices are available at the moment), also the adapter handles all the low level detail (misalignment, dtack, wait-cycles, physical size-cycles e.g. a NVRAM of 8bit attached to a 32bit data bus, etc), and back propagates a feedback to the core_bus: { success, failure&cause }

the cpu doesn't care about those details, it's not like on a MIPS processor where you have to physically handle the misaligned access with a specific pair of instructions, it's more like the 68000 cpu

in case of failure an exception is also raised and the cop0 (exception handler) will look at the cause- register in order to issue the right ISR-vector to the cpu: bus error exception




not yet completed, it's based on an old working project I done 3 years ago, it's the first on the left in the picture, whereas the last one on the right is the current project, completely rewritten from the scratch, you can see a few progress 

[rstofer]

I haven't progressed to the point of using 'records' for data structures.  I can see where they can be used to encapsulate a group of signals and  next time I code my 1130, I'll try that for all of the IO devices.  They all work the same way:  They have a device id, the use the DMA channel for all transfers which implies an address bus, a REQ/GRANT arrangement and so on.  This could save me some states by eliminating code that  now talks to a particular IO device.

From the point of view of the DMA channel, all devices are equal in terms of hardware including the CPU.  There is a priority encoder scheme to keep the CPU from hogging but that detail is internal.

Yup!  Something else to study...

[rstofer]

At around 17 minutes in this video, there is a discussion about building MUXes and the best choice seems to be the CASE statement rather than the if-then-else which actually builds a priority tree.  I'm not sure what the 'when' arrangement creates but I wouldn't be surprised that it looks like the if-then-else situation.

In any event, this video was 47 minutes well spent.  There is quite a discussion on FSMs and pipelining:

http://www.xilinx.com/video/hardware/basic-hdl-coding-techniques.html

[legacy]

In any event, this video was 47 minutes well spent.  There is quite a discussion on FSMs and pipelining:
http://www.xilinx.com/video/hardware/basic-hdl-coding-techniques.html

it's always time well spent when it also offers an occasion to improve my English
thanks twice, it's also a very very nteresting video