Pullup settings for ECP5 fpgas

[Jo mo]

Hola

At first Democrito was using an ice40 pullup block in his nrf24l01 design, so i started trying to make pullup works on ecp5 !

@ Fernando(Benitos), are you sure that the pullup block (with a primitive in the verilog code) was really making a pull up function in your Megadrive_ECP5_test.ice file ?

picture of the code in pull up ecp5 block !

i tried to use it but could not fin a way of making it work!

What i think i understood with icestudio:
- in ice40 fpgas the pullups are set with primitives in the verilog file sent to yosys.(so we can just use the icestudio pullup .ice blocks)
- in ecp5 fpgas the pullup are not set in verilog! they are set in the main.pcf file (generated by compile.js which read the info from pinout.json when we build a project). and this .pcf file is then used by nextpnr.

So if i am right, using icestudio (pullups cannot be set with primitives in verilog code).
 
I am thinking, for ecp5 boards only, in solution of adding a "pullup" checkbox in the dialog box of the input ports block (form.js).
 and modify the compiler.js to be able to read the "pullmode" not only from pinout.json but also from each of the input ports pull up check boxes.
 

Before, i investigate further, Do you guys have any tough about that subject!

Have a nice day

[charli va]

Hi Joaquim!! If you research this tell me and i implement all of you found!! Thanks a lot!!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/8cc47443-d5d2-4b5d-b4ca-606ecce6e0dfn%40googlegroups.com.

[Jo mo]

Ola charly,

The idea will be to add a "pull mode" combo box with the options (default, up, down). default being the pull mode value specified in pinout.json for that board

and then when compiling the project, compiler. js takes the combox value sored for each input pins for generating the pcf files!

and that combo box should only be visible for ECP5 boards(not ice40).

remark: i tested forcing compile.js  affecting pulmode to "up" and it worked means all the inputs used in my design where set electrically to pull-up mode!

[charli va]

Thanks Joaquim!! give me some days because i'm working in a  new board panel that i pretend publish the next week, and this would be a big great feature for it.

Thanks again for your great ideas!!, as soon as possible i put this kind of selector public.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/07f9bb37-7417-4635-b001-0ab398d1616dn%40googlegroups.com.

[beni...@gmail.com]

Hello JoMo and Charliva

In my last version of the Megadrive_ECP5_test I am using another type of Pull-up. The Universal Pull-Up  is valid for ICE40 and ECP5

In the attach file you have the Universal Pull-up module

Please, try this one and tell me if is working

Regards

Fernando

[beni...@gmail.com]

You have in this image the last project I did. Please , don't forget to introduce minimum 3.3 V in the pin 5 of the controller 

I have add the project in the attachment files 

Regards

Fernando

[Jo mo]

ola Fernando,

Thank a lot for you reply,

i just tested you new block alone in a design and unfortunately, it doesn"t do the pull up function, for me !?

i have always 1 at the output of the block! (even when i inject a zero at the input)!

Remark, i also compiled directly your megadrive...file. at it generates the following .pcf file (with a none for every input pullmode)

but i suppose thaht your verilog code is aimed to configured pull ups not trough the pcf file but trough verilog + yosis ! but no luck here ;-)

have a nice evening!

[Jo mo]

Sorry, i forgot the lpf file (and not pcf)

[Jo mo]

Ok guys,

After one week of experimenting with this pull-up configuration, I think I’ve found a way to make the setting from the Verilog code possible, without modifying the pinout.json for every design!

So, Charly, there’s no need to add a special checkbox in the pins dialog box for pull-ups!

First: The correct Verilog code to set an ECP5 pull-up in our icestudio blocks is as follows:

a) The one used by Fernando in his first version of Megadrive!

b) Alternatively, we can use the modules (Verilog code) included in yosys (C:\Users\yourself.icestudio\apio\packages\tools-oss-cad-suite\share\yosys\ecp5cells_io.vh).
   module IBPU (input I, output O);
        (* PULLMODE="UP" *) TRELLIS_IO #(.DIR("INPUT")) _TECHMAP_REPLACE_ (.B(I), .O(O));
    endmodule

As you can see, these modules call the right ecp5 primitives (TRELLIS_IO #) (like Fernando does). So, in our case, we can use the following icestudio block:
    IBPU my_beautiful_pullup_nb_1(.I(i), .O(o));

Second: When building the project, both Verilog solutions (a and b) have the effect of adding a “PULLMODE”: “UP” to the hardware.json file generated by YOSYS.

However, there is a problem! When we launch nextpnr-ecp5, it receives two inputs:

- a “PULLMODE”: “UP” information from our hardware.json.
- a “PULLMODE”: “NONE” information from the main.lpf file (also generated by icestudio but based on the info found in pinout.json for our board).
Unfortunately, the winner is “NONE” from main.pcf! I tried playing with nextpnr options to override this info from main.pcf but was unsuccessful (it’s probably possible using a script, but I’m not sure).

To solve this issue, I modified the compile.js file in icestudio (which generates main.lpf).   The trick is to change the line:

code += 'PULLMODE=' + pullmode;
to:
    if (pullmode == 'UP'|| pullmode == 'DOWN'){
                code += 'PULLMODE=' + pullmode;
    }

So in the end, if pinout.json (board constraints) has a pullmode set to UP or DOWN, then the FPGA pin will be set to 

So in the end, if in pinout.json (board constrains) we have a pullmode set to UP or DOWN then the fpga pin is set to that mode !
And in the opposite case (NONE or anything-else), then the pullmode can be set inside our icestudio blocks with verilog)

if you want to try, i am joining:

 - the  testecp5pullup .ice file

-   and the compile.js ( for this one you have to replace in the name .txt by .js)  (shitty "google group" limitation on the up-loadable files types)

@ Fernando: If you see a problem with this, just let me know.  If not, I can submit a pull request for that little change!

I also want to pull-request the addition of the pull-up blocks to the IceIo collection.

@ Fernando: Which solution do you prefer, a) or b)?

With a), we have a clear view of the use of primitives directly inside icestudio. It’s good for playing with the code.
With b), the primitives are hidden in yosys, but when yosys is updated, the blocks are also automatically updated!

Two side remarks:

 @juan  @Carlos:  In the last yosys versions (not the one we have now in icestudio), the cellio.vh file includes the line:
          module IBPU ((* iopad_external_pin *) input I, output O); (* PULLMODE="UP" *) TRELLIS_IO #(.DIR("INPUT")) _TECHMAP_REPLACE_ (.B(I), .O(O)); endmodule
As you can see, there is a new attribute (* iopad_external_pin *) before an input port! 

Actually, in icestudio, we cannot add those kinds of attributes for ports (if needed someday). Because in Verilog, those attributes need to be inserted just before the port names! 

And to get that, we will need:

  1- to modify the parsing of the data entered in the "input/output ports" dialog box of our code block. To make it accept attributes (eg: like (* iopad_external_pin *)   )

  2- ensure that this new information is correctly added to the main.v file ( means checking code += in compile.js , around line 110)

I can try to have a look at that implementation , what do you think ?!

@ Fernando: A little comment about “The Universal Pull-Up” (valid for ICE40 and ECP5) Verilog code you used in your last version of Megadrive project:

    // Universal Pull up
    assign o = (i===1'bz) ? 1'b1 : i;

As I understand it, this doesn’t really set a pull-up resistor at the input! 

It tries to test if the input is Hi-Z (unless I am wrong; I think this test is not possible with FPGAs as it’s a bit too complicated to implement in the electronics of the chip for every pin). 

If I understand correctly, that “bz” should mainly be used for setting  the outputs to high-z !

Sorry for that long, dirty post  ;-)

Have a nice week guys!

[beni...@gmail.com]

Joaquin

     

     Thanks for all your experiments and for discover the problem with the pull-up in ECP5 boards.

      I think the best option is the a)  , because is the same option you have for ICE40, using the primitive for that
      Your solution modifying the compile.js file is also Ok for me.

      So, make the changes you considerer they are easier for the users and pull request the changes when you want.

    

      Thanks again for the excellent job !!!

      Fernando

[charli va]

Hello Joaquim!!!! great job!! thank you so much!! i hope the variety of films that you watch the last weekend inspired you a lot, they say that we are the books we read, the movies we watch...

For me option a) is the best, for the same reasons that Fernando says. I think it's best to try to unify solutions between cards if possible. Release your PR whenever you want!

For the rest, I have been working on many new things for the last few months, I hope to publish them very soon, I am very close to having a stable code, among these new features, there is the option to use external toolchains (so as not to depend on celery if you don't want to, for example use the latest version of yosys directly). On the other hand, I will try to update celery this week to have the latest version of yosys operational in icestudio.

Other things that we will publish soon will be the possibility of using cables of variable length (we could generalize many blocks) and I think it could be very easy for the code I am working on to include this type of options (iopad_external_pins).

Another improvement I'm preparing is a toolbox for working with pcf files and the ability to include a custom pcf in your .ice file (the idea is that anyone can modify distribution pcf files by code).

Thanks again, you're awesome!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/93a1b717-62dd-42b1-bb40-3adbc991e66cn%40googlegroups.com.

[Jo mo]

Gracias Fernando and Charli for your replies/comments!

I will try to PR that pico-change tonight,

@charli: Well personally, I'm trying to check/crosscheck/keep a critical eye on all the info i get (from books, movies, tv, internet,...). Before allowing that info to modify what i do, what i am !

An info, by definition, comes from a person who has his own interest in giving us that info. That interest may be incompatible with ours own interest, but potentially, we can be manipulated without even detecting it!

About celery, before today, i knew it only has a Legume :-)

Good luck for the mods you are working on Charly, they look interesting! Do not hesitate to publish them early, we can try to help you finding the bugs in the wip versions!

About toolbox for pcf files, it is a good idea!

Has i see it, the good will be to just have the possibility to override some (precise user choose ) info which is already in our board pinout.json. 

Because, the possibility to have a full pcf file manually loadable by the user, seams, to me, source of errors on the user side !

On my side, in the following days, i will try to test and add some other ecp5 io-blocks (i could test already IBPU, IBPD, OBZ)

Have a nice day guys,   and you are awesome too ;-)

[charli va]

Jajaja celery!! the stupid mobile auto correction bot XD apio in spanish means "celery". 

I'm publishing new things very soon, i'm counting with all of you to test it and give  me a lot of feedback.

Have a great day team!!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/8d96820b-24ca-47fb-bc0a-31aac3e00fa6n%40googlegroups.com.

[Jo mo]

JaJa so nothing to do with that vegetable software

People have create a software with every possible vegetable names!

What a pity,....we could have choosen the name "gaspacho" instead of  "icestudio"  :-)) ?

[charli va]

Or paella maybe XD!

Dont forget that inside our precious chips are wafers 😂 https://www.google.com/search?q=wafer&sca_esv=568775834&sxsrf=AM9HkKnqJZF9gbSg_hIFaovlynZGZqnRFg%3A1695805276137&ei=XO8TZfX7B-nKkdUPl-G5sAg&ved=0ahUKEwj1md74tsqBAxVpZaQEHZdwDoYQ4dUDCBE&uact=5&oq=wafer&gs_lp=Egxnd3Mtd2l6LXNlcnAiBXdhZmVyMg0QLhiKBRixAxiDARhDMgcQABiKBRhDMggQABjLARiABDIFEAAYgAQyBRAAGIAEMgUQABiABDIFEAAYgAQyBRAAGIAEMgUQABiABDIIEAAYywEYgAQyHBAuGIoFGLEDGIMBGEMYlwUY3AQY3gQY3wTYAQFI9BRQAFi8CXAAeAGQAQCYAXygAbEEqgEDMS40uAEDyAEA-AEBwgIMECMYigUYExiABBgnwgIEECMYJ8ICBxAuGIoFGEPCAgsQABiABBixAxiDAcICDRAAGIoFGLEDGIMBGEPCAgcQIxiKBRgnwgIREC4YgAQYsQMYgwEYxwEY0QPCAggQABiABBixA8ICCxAuGIAEGMcBGNEDwgIOEC4YrwEYxwEYsQMYgATCAg0QLhiDARixAxiKBRhDwgILEC4YgAQYsQMYgwHCAgQQABgDwgIFEC4YgATiAwQYACBBiAYBugYGCAEQARgU&sclient=gws-wiz-serp

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/69ec52a8-415f-48e0-939f-94898bf813c7n%40googlegroups.com.

[Jo mo]

Ola Fernando,

Sorry to disturb you again, but you are our ecp5 specialist  ;-)

In fact the mod i did in compiler.js. has the effect of not taking in account the pullmode = None on all the pins in pinout.json files (for ecp5))!

And as with ecp5 by default the inputs are connected with a pull-down (pullmode=Down)!,

it means the following design includes automatically a (not visible) pull-down at the input P3-C4 !

Maybe it was to avoid that (a bit counter-intuitive) situation , thaht you started specifying a "pullmode=None"  (instead of not mentioning at all the pullmode) in all your ecp5 pinout.json files ?!

So the question is:

a)- Should we have as default, for every unconnected pin, a pull-down mode (as Lattice did for ecp5 family) . 

Means all our unconnected fpga pins will be weakly connected to low (hopefully improving noise immunity).

A pull down will not arm in the vast majority of applications !

But if an application requires it, we can use a ''pull-NONE" 'block to unconnected that default pull-down for a specific input pin

I am joining the above pull none block ( i tested it, at it works as expected) !

 
b)- or should we force (has you did initially in pinout.json) all the inputs to pullmode = None!
And then my compiler.js mod, which allows the setting from verilog of all the 3 pullmodes (up,dow,none) doesn't work any-more !

and we have to:

-  b.1: find the right way of having NextPnr able to override the main.lpf (/pinout.json) info by the hardware.json info

-  b.2: find a way that icestudio code injects the verilog info inside the lpf file. overriding some board constrain ( Maybe, with the lpf mod that carlos is working on).

Any thoughts about the 3 possibilities, from your sides!

have a nice week-end guys

[charli va]

Hello Joaquim! I'm going to evaluate what you tell us, this afternoon I'll get to work on it. I want to do some tests before giving you any clear answers.

Thank you very much again for your work Joaquim! Thanks to feedback like yours, we will make Icestudio a great tool.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/cfc7eaa4-28b9-42f3-832c-3d3726d726a2n%40googlegroups.com.

[charli va]

Hi at all! i'm working on it, in the next days i'll send you a proposal , ok? i'm not forget this issue, is very important!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/cfc7eaa4-28b9-42f3-832c-3d3726d726a2n%40googlegroups.com.

[Jo mo]

Ola Fernando e charli,

For now i could prepared some io block ( pull-up, pulldown, pull none, tristates) thaht i just pull requested in the iceIO collection!

They work with the "verilog to yosys" way (with the compiler.js mod i pull requested last week, and active in the current wips)!

Now i am trying to make a "OBCO block" (output buffer complementary output (ouputs a differential pair (like LVDS) ) and i have the same difficulty that i got with the pullmode attribute but this time with the " IO_TYPE " attribute that i want to set to "LVDS".  actually the compiler.js set all inputs and output  to " IO_TYPE=LVCMOS33"

For me, in the end, the proper way of using this "attributes" (like pullmode ) is not by updating by updating the main.v (which goes to yosys).

Eanstead, we have to update the .LPF file and send this file to nextpnr (so yosys do not need to know about those attributes).

If we read the lattice TN-02032, we see that for ECP5 family we have plenty of different attributes that can each one have plenty of values!
remark: for ice 40, in the .PCF file it is much simpler (just few possible attributes with few values )

To make the story short, to help the user dealing with those attributes, we need one of the 2 following solutions:

- as charli said, add in icestudio de possibility to insert a .LPF file (made manually) which will replace the one actually generated by icestudio (which is not good enough for ecp5 possibilities)
- add an "advanced" button in the input and output dialog box. that button will open a new window which will allow the user to set all the values for the attributes.
then icestudio compile.js will use those information to edit the LPF file in a proper way!

The second solution seams more user friendly but there is some works for implementing it!
i can try but it will take me quite sometime! maybe we can share work with charly!

Again, if you have any thoughts on the subject do not hesitate to mentioned them here! 

Because It is better not start working on implementing the "advanced option" button and at the end no one want it ;-)

So for now we just have the pullmode attribute working (and as i mentioned in an earlier post with a default value pullmode = pulldown, i think this is good)

Ok, charli no problem, we wait also for you proposal! An decide after !

Have a nice evening guys

[charli va]

Hello Joaquim!! Thanks for your thoughts! I am preparing a proposal and will send it to you very soon, and if you want to help me implement it, I will be very happy to hold your hand and help you along the way!

The idea of the custom pcf is not just to attach a pcf file, my idea is like the one you propose, a friendly interface that allows you to configure your board for the project, I have advanced work in this way, very unstable, but in the next few days , I will stabilize it and throw it to you in one of the following wips.

In the next few wips, I intend to put in a lot of new features that I'm working on, but I don't want to put in a lot of unstable code all at once. If it's okay with you, we'll go step by step by step.

A huge hug and thanks for everything!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/f780c84f-f30b-4efc-9764-e763873aeec8n%40googlegroups.com.

[Jo mo]

Yes, charly, step by step on all subjects, is fine for me ;-)

And about ecp5 i/o, to test your changes we can start with just one attribute! (eg: the "pullmode" with his 3 values up, down, none )

Big hug to you!

[beni...@gmail.com]

I think this option is the clearest 

Joaquim, Do you have the new io block ( pull-up, pulldown, pull none, tristates)? 

Thanks and regards

Fernando Mosquera

[Jo mo]

yes Fernando , they are in the iceIO collection !

regards

[beni...@gmail.com]

Thanks Joaquim I have already install in my IceStudo

Regards

Fernando Mosquera

[Jo mo]

I think i wrote "bullshit" few messages ago on this tread :-)

By playing again with compiler.js, I think I have found a way to pass the “IOtype=” attribute with verilog code, instead of using the .lpf constrains file.

This might also work for other attributes (other than pullmode and IOtype).

I need to verify this idea a bit more, and I will update you tomorrow.

So charli, if you can put on hold the mods on the inout pins dialog box, it will be great!

[charli va]

Dont worry Joaquim, take your time, the board editor is in my roadmap, i put on hold this feature about this attributes until you clear our vision about it!

Thanks a lot for your effort!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/a6440880-048b-496a-848a-2f90b73e079cn%40googlegroups.com.

[Jo mo]

Ola guys,

So, i made my OBCO block  ( differential output block)  for ecp5 work.

I had to remove from compiler.js (for ecp5) the code which injects an IOTYPE constrains into the main.lpf file

And that way, nextpnr will take in account the attribute (*IO_TYPE="xxxxx"*) coming from icestudio verilog code (trough yosys)
In fact, it is similar to the mod i made to get the pullmode attribute support in verilog.

In the end compiler.js will only inject in main.lpf :
- the net to fpga pin affectation (that we connected in our .ice designs)
- and of course all the constraint from the pinout.json where we should have the hardware constraint that were designed during the PCB design of the fpga board)

So i removed the  IOTYPE constrains writing from compiler.js (see joined file, you need to change the .txt  extention to .js)

And with that i could build and load a differential pair output design.  where the  IO_TYPE="LVCMOS33D"    (D is for differential)  attribute is passed trough verilog code.
see the joined .ice file

Here is a little measurements on my ecp5 board: the input signal is a pulse of 10 ns every 100ns (10 Mhz) .


But in fact to see the gain of using those paired pins for differential pairs (against using 2 random pins of the fpga and just using a not gate to make the complementary output), we should probably use more difficult conditions ( transmit higher frequencies and long wires between the transmitting fpga an the receiver of the signal, in a noisy environment)

i can not test faster stuff my logic analyzer is limited to 100mhz sampling rate!

If no one sees a problem, i will pull request this little compilers.js mod and add this block in iceIO collection !

Have a good evening.

[charli va]

Hi Joaquim! Very smart solution, I am very happy with it.

I've tested five designs to make sure previous things don't fail and it seems to work fine.

I can't test the differential block because I'm away from home this week and I don't have an oscilloscope or hardware but I will do it this weekend, if you define a "simple demo" with external hardware that we can test it, count on me.

For me, go ahead and push!

Thank you a lot!!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6e1b90a5-2e81-48d7-b261-df7b8c489513n%40googlegroups.com.

[Jo mo]

Ola Carlos,

So as you have seen i pull request the changes ! With still my unsigned commits problem ;-).

Remark: the compiler.js file that i posted 2 posts ago was a draft version(with a little problem), in my PR it is the correct version!

Joined is an *.ice example of use of this block!  

As you can see in icestudio we only need to set one of the two pins of the differential pair (the other is automatically connected)!

All you need to test it,  is:

- an ecp5 board (and you modify the output pin to set to the diff pair you want)

- a measurement system  (at least 50 Mhz sampling rate) to measure the signal on the 2 pins of your differential output pair

here i used a my logic analyzer.

Have a nice day

[charli va]

Thanks Joaquim!!! your PR is merged!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/89f5aaac-0301-4f76-9623-7aeeaab0343dn%40googlegroups.com.