Closed RGD2 closed 8 years ago
Some simple examples with .PLLOUTGLOBAL(clk)
work for me. I fixed https://github.com/cseed/arachne-pnr/issues/20. Please try again. If it is still failing, would it be possible to get a test case? Thanks the bug reports and your patience!
I'm getting this one again - but this time, no PLL about. (probably not exactly the same bug), but it's happening whenever I try using .CLOCK_ENABLE with an SB_IO: This is with 6b83364
route...
n _spi.ince cn 80913 cnet_net[cn] _extraio.we
arachne-pnr: src/route.cc:653: void Router::route(): Assertion `cnet_net[cn] == nullptr || cnet_net[cn] == n' failed.
I'm trying to get a little SPI master module working - it's outputting just fine. clk is a 40 MHz clock, and SCL needs to go 20 MHz, which it is: output is working just fine, and I only need the 5th to 15th bits of the input to work, but currently I'm getting nothing back in. The slave devices both sample and transition their outputs on negative SCL edges, so I'd like to use SCL_ as below to enable the input clock, but arachne-pnr is spitting the dummy at it. If I leave .CLOCK_ENABLE open (which is recommended to do to have it stay enabled) then it seems to compile ok, but wiring the MOSI and MISO pins together and outputting $ffff just results in getting back only zeros.
My 'scope shows the data coming out just fine, but the input pin just doesn't respond to it.
(SPImaster.v ):
module spimaster (
input wire clk,
input wire we,
input wire both,
input wire [15:0] tx,
output reg [15:0] rx,
output wire running,
output MOSI,
output SCL,
input MISO);
reg [15:0] sdelay;
assign running = sdelay[15];
reg [15:0] dataout;
wire MOSI_ = dataout[15];
reg SCL_;
wire MISO_;
wire ince = ~SCL_;
always @(posedge clk)
begin
if (running) begin
sdelay <= SCL_ ? sdelay : {sdelay[14:0], 1'b0};
dataout <= SCL_ ? dataout : {dataout[14:0],1'b0};
rx <= SCL_ ? rx : {rx[14:0], MISO_};
SCL_ <= ~SCL_;
end else begin
SCL_ <= 1'b1;
rx <= rx;
if (we) begin
sdelay <= both ? 16'hffff : 16'hff00 ;
dataout <= both ? tx : {tx[7:0],8'b0};
end else begin
sdelay <= sdelay;
dataout <= dataout;
end
end
end
SB_IO #(.PIN_TYPE(6'b0101_01), .PULLUP(1'b1)) _scl (
.PACKAGE_PIN(SCL),
.CLOCK_ENABLE(),
.OUTPUT_CLK(clk),
.D_OUT_0(SCL_));
SB_IO #(.PIN_TYPE(6'b0101_01)) _mosi (
.PACKAGE_PIN(MOSI),
.CLOCK_ENABLE(),
.OUTPUT_CLK(clk),
.D_OUT_0(MOSI_));
SB_IO #(.PIN_TYPE(6'b0000_00), .PULLUP(1'b1)) _miso (
.PACKAGE_PIN(MISO),
.CLOCK_ENABLE(ince),
.INPUT_CLK(clk),
.D_IN_0(MISO_));
endmodule
Any ideas?
Tried this too, dies with the same exception message: (SPImaster.v 'v2'):
module spimaster (
input wire clk,
input wire we,
input wire both,
input wire [15:0] tx,
output reg [15:0] rx,
output wire running,
output MOSI,
output SCL,
input MISO);
reg [15:0] sdelay;
assign running = sdelay[15];
reg [15:0] dataout;
wire MOSI_ = dataout[15];
reg SCL_;
wire MISO_;
always @(posedge clk)
begin
if (running) begin
sdelay <= SCL_ ? sdelay : {sdelay[14:0], 1'b0};
dataout <= SCL_ ? dataout : {dataout[14:0],1'b0};
rx <= SCL_ ? rx : {rx[14:0], MISO_};
SCL_ <= ~SCL_;
end else begin
SCL_ <= 1'b1;
rx <= rx;
if (we) begin
sdelay <= both ? 16'hffff : 16'hff00 ;
dataout <= both ? tx : {tx[7:0],8'b0};
end else begin
sdelay <= sdelay;
dataout <= dataout;
end
end
end
wire sclin;
SB_IO #(.PIN_TYPE(6'b0101_01)) _scl (
.PACKAGE_PIN(SCL),
.CLOCK_ENABLE(),
.OUTPUT_CLK(clk),
.INPUT_CLK(clk),
.D_OUT_0(SCL_),
.D_IN_0(sclin));
wire ince = ~ sclin;
SB_IO #(.PIN_TYPE(6'b0101_01)) _mosi (
.PACKAGE_PIN(MOSI),
.CLOCK_ENABLE(),
.OUTPUT_CLK(clk),
.D_OUT_0(MOSI_));
SB_IO #(.PIN_TYPE(6'b0000_00), .PULLUP(1'b1)) _miso (
.PACKAGE_PIN(MISO),
.CLOCK_ENABLE(ince),
.INPUT_CLK(clk),
.D_IN_0(MISO_));
endmodule
I am getting very odd behavior with this crash, @cseed .
Ran the following and got the same crash 3/3 times:
arachne-pnr -r -m 500 -d 8k -P ct256 -p j4a.pcf j4a.blif -o j4a.txt
j4a.blif_crashes.txt j4a.pcf_crashes.txt
What's odd about it, is that messing with the SB_IO's in the spimaster module stops the crash... but the crash is complaining about signals attached to SB_IO's defined elsewhere, specifically:
route...
n _mod.we cn 80913 cnet_net[cn] $true
arachne-pnr: src/route.cc:653: void Router::route(): Assertion `cnet_net[cn] == nullptr || cnet_net[cn] == n' failed.
Aborted (core dumped)
So... wtf?
Here's the blif that doesn't crash arachne-pnr, but it is still broken as the SCL output doesn't work (it just stays high all the time, but I can see MOSI toggle ok.)
j4a.blif_doesnt-crash-but-still-broken.txt
Are these test case blif's enough @cseed ?
@RGD2 I can reproduce the j4a failure, looking into it now. I wasn't able to reproduce the spimaster.v crash with version https://github.com/cseed/arachne-pnr/commit/6b8336497800782f2f69572d40702b60423ec67f. Any chance you have a .blif and an arachne-pnr command line to reproduce it?
Ok, I'll update and give it a try...
Seems to compile without error now with Arachne-pnr e0d7af8, based on newer code with .CLOCK_ENABLE(ince) added to MISO like the above examples.
I'll have to test this when I get back to work tomorrow. (It's 8PM here now, and I didn't leave a ice40hx8k plugged in at work).
I'll reopen this if the error shows up again, but passing compilation is enough for me.
Confirmed fixed
RGD2, I'm reopning the issue because I can reproduce the j4a crash. I see what the problem is: you have two incompatible SB_IO mapped to the same tile. PA[7]
has clock enable _mod.we
and MISO has clock enable $true
, but those signals are shared (net 80913, 20 0 io_global/cen). I'm working on a patch to generate an error message in this case.
OK, should be fixed now: https://github.com/cseed/arachne-pnr/commit/649abf88a0b9ea5f0bf3e62f6e7f6030d5b691e2.
on 52e69ed, and it's still compiling without error... but (and perhaps I didn't notice it before) SCL, which is on pin P10, just stays low.
I'm stuck here. AFAIK spimaster.v works standalone as I would expect : spimaster.v.zip
But just not within the j4a. So it's got to be down to something odd happening due to the different configuration around it.
I have an example project here: RGD2/ice40_hwtest/tree/spimaster But, it works as expected. The version of spimaster.v I made there is a hard-symlink to the one in my j4a repo. (Ie, literally the same file).
Should we reopen, or would you like me to make a new issue?
I tried swapping (in the PCF) PA[7] with SCL, and this does give the error message you added. Is there any easy way to check the database for which pin names share which IO blocks?
@RGD2 gawk '/^\.pins ct256/,/^$/ { print; }' /usr/local/share/icebox/chipdb-8k.txt
(or simply open /usr/local/share/icebox/chipdb-8k.txt
in a text editor and look for the right .pins
section.
The lines in those .pins
sections look like this:
B10 24 33 0
B11 23 33 1
B12 24 33 1
The first line means pin B10
is in the IO block with coordinates 24 33
and is in position 0
within that block. Looks like pin B12
occupies position 1
in that same IO block.
Thanks Clifford!
I found this gives a list a little easier on the eyes: sorted by IO block. It's a csv because for some reason sort had trouble otherwise.
(echo "pin,x,y,id"; gawk '/^\.pins ct256/,/^$/ { print; }' /usr/local/share/icebox/chipdb-8k.txt | sed 's/.pins ct256//g' | sed 's/\ /,/g' | sort -t, -k2n,3n)
Ok, so this is a little easier to use - but still not quite complete enough by itself to choose pins. It's got to be used alongside the pinout xlsx, since that one includes all the alternate functions as well -- but the latter doesn't tell you how the pins pair up. Oh well.
I'm going to continue trying to isolate this issue.
I have a workaround, but I don't know why it works. (it makes no difference in my isolated test case, with no changes to the SB_IO instantiations between it and the j4a integrated case.).
in my j1a/icestorm/j4a.pcf file, I changed:
set_io MISO N10
set_io SCL P10
set_io MOSI N12
to
set_io MISO N12
set_io SCL P10
set_io MOSI N10
... and now SCL is working. This seems to make sense - both pins in the same IO block now have the same settings. Yet, in the isolated version it works either way around.
bins are attached,
SB_IO_Woe.zip
both load into a machxo2bb, and I was testing the SPI module with swapforth code : testout $aa55 $c0 io! begin $80 io@ until ; ' testout $100 io!
, then looking at P10 with an oscilloscope.
This seems to be triggered by using
.PLLOUTGLOBAL(clk)
instead of.PLLOUTCORE(clk)
Maybe related to #20 ?