std::out_of_range exception in src/global.cc:242 about arachne-pnr HOT 6 CLOSED

Ok I have done some research and here are findings.

In project icestorm there is generated file chipdb-1k.txt that contain list of GLOBAL_BUFFER_OUTPUTs

.gbufpin
13 8 1 0
0 8 1 1
7 17 0 2
7 0 0 3
0 9 0 4
13 9 0 5
6 0 1 6
6 17 1 7

If we check tile 248 (hex F8) we will find that it is tile : F8=10 + 14*17 , and that correspond to PIN 116 for tq144 ( 116 10 17 1 )

And we can see that value is not in gbufpin list, so it can not be used.
If I map gbufpin this to pins I get list : 93,21,128,50 ,20 ,94 ,49 and 129
So those are the pins that should be used.

For 8K build pin H16 ( location 33 17 0) is used, and that one is also in gbufpin list for 8k, so that is reason why that is working.

My suggestion is just to add check if pin is contained in list, and if not give error back to user.

from arachne-pnr.

Here is a patch I had on mind:

 src/global.cc | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/global.cc b/src/global.cc
index bf5d00c..79d12ea 100644
--- a/src/global.cc
+++ b/src/global.cc
@@ -239,7 +239,10 @@ Promoter::promote(bool do_promote)
           Port *out = inst->find_port("GLOBAL_BUFFER_OUTPUT");
           if (out->connected())
             {
-              int g = chipdb->loc_pin_glb_num.at(chipdb->cell_location[c]);
+			  auto loc = chipdb->cell_location[c];
+			  if (chipdb->loc_pin_glb_num.find(loc) == chipdb->loc_pin_glb_num.end())
+				  fatal(fmt("Not able to use pin " << ds.package.loc_pin.at(loc) << " for global buffer output"));
+              int g = chipdb->loc_pin_glb_num.at(loc);
               for (uint8_t gc : global_classes)
                 {
                   if (gc & (1 << g))

from arachne-pnr.

Thanks! That actually makes a lot of sense.

Sadly that means that the HX1K IceStick does not have a single GBIN pin on a header...

from arachne-pnr.

Sadly that means that the HX1K IceStick does not have a single GBIN pin on a header...

Yes. I've heard people complain about that before.. :)

But if you can afford the slight additional delay you can still route to the global net via the FPGA fabric. Use the SB_GB to do that. (But if its a clock then arachne-pnr will instantiate the SB_GB automatically for you in most cases.)

from arachne-pnr.

Thanks for the hint!
I think this is feasible here and I just implemented it :).

from arachne-pnr.

@dpiegdon No problem, glad I could help. Was interesting to get more into this tool source and better understand Lattice internal organisation.

from arachne-pnr.