I think they used to be a shared bus but it was sp...
# shuttle
m
I think they used to be a shared bus but it was split and the oenb remains.
p
Okay, got it, thanks, this is helpful. I was ignoring oenb, sounds good that I don't have to fix that.
Okay, just to be very very explicit, do you believe that my user project should be driving the
la_data_in
pins or the
la_data_out
pins? At first I assumed I should be driving the
la_data_in
pins, because I assumed they were the inputs to the LA, but now I'm thinking I should be driving the
la_data_out
pins (as in, they are the outputs from my user project). Do you know which way around it is?
From looking at the
user_proj_example.v
it sure seems like this new interpretation is correct (i.e. I should be driving the
la_data_out
pins, not the
la_data_in
pins).
Sorry, I know I'm asking this a ton of different ways, because I'm trying to be super duper certain I'm getting this the right way around. In the Verilog I see:
Copy code
input  [127:0] la_data_in,
    output [127:0] la_data_out,
    input  [127:0] la_oenb,
In the .lef I see:
Copy code
la_data_in[0] is DIRECTION INPUT
  la_data_out[0] is DIRECTION OUTPUT TRISTATE
  la_oenb[0] is DIRECTION INPUT
From this I am inferring that the
la_oenb
pins are being driven by the Caravel harness itself (and should not be driven by my user project), and I should be driving the
la_data_out
pins (and not the
la_data_in
pins).
Does the above summary agree with your understanding?
m
Yes
The example project uses la so you always refer to that. And your testbench will fail if you have the pins connected badly.
And yes you can ignore the enable signal
Also, better place to discuss this is in the caravel channel, it's definitely come up before
p
@Matt Venn Got it, thanks so much! Also, I didn't know about the caravel channel, thanks a ton, I'll join it.
👍 1