Icestudio Code Block Configurator Modal Window

[cavearr]

Current problems

• The management of ports in code blocks is very complex when you have many ports.
• The input is annoying to manage a lot of ports or with long names.

Proposal

The current view could be maintained in the manual tab to maintain backward compatibility with current tutorials or articles.
Mutate the current modal to a new one based on tabs; the new tabs are:

1. Inputs
2. Outputs
3. Tristate
4. Parameters
5. All
6. Manual
7. Tools

Tabs

Inputs / Outputs / Tristate / Parameters

This tabs contains the list of this class of IO, the user could add, remove or reorder it.

All

This tab contains all of the IO, merged in one place

Manual

The current modal

Tools

Contains buttons with Tools, for example our Import verilog
Other interesting tool is Export button to open other options modal that permits export to excel, csv, html table (for documentation purpouses).

Tab definition

Each tab contains a grid with the definition of its io class (inputs, outputs,...) and the options for this kind of input.

The grid should have the next functions:

• Capability of copy/paste
• Reorder lines (position of the IO)
• Add a new row (button with label Add)
• Remove a row. (button with label Remove)
• Select the options for this class of IO
• Select the color for the port (this will be a new feature to colorize wires from port definition).
• Enable checkbox (enable by default), this is for debug purposes, a lot of times you are developing and need to add ports to debug or for develop needings, is very anoying all the time remove and write the ports you need. With this feature we could have the block configuration and display or not ports depends of this check. This connect other new feature that i'm working to have a global debug check that you could activate or deactivate and link parts of the design (signals, ports,etc) to it. This implied save in the codeblock model new variables that define the render of this ports.

This is a proposal for example for the tab All

examples.zip

And other concept for tab Manual:

I'm attaching the source code of the example; this is very basic. I'm using an Excel-compatible library that is very useful, but we need to see if it's capable of limiting its capabilities and customizing it as we want (the library is now available in Icestudio for other features; I included it a while ago). Some things to keep in mind:

• Users might not be able to order by columns because the order of the inputs is defined by the table's order. In the example, you could order by dragging files up and down (this should be the only capability users have), and in the example, you could reorder by columns (we need to avoid this).
• It could be interesting to avoid the right mouse button context menu.
• We could use another library or do it manually with standard elements (tables, divs, selects...).

Functionality

All tabs work like a wizard; in depth, all tabs grab and load data to and from the Manual tab (the current inputs).

[cavearr]

📢 @lmcapacho @jojo535275 @Democrito @Obijuan @TimRudy

[jojo535275]

Hola guys,

I think it is a good idea to facilitate the management of I/O/parameters !

My personal preference, will be to not have too many tabs where we can enter the same information (even if as you wrote, their are all automatically updated/synchronized ).
Maybe i will keep just the 3 tabs ALL, Manual, tools (maybe also renaming them).
We can also imagine to add a filter just above the spread sheet part. something like this:

But has all different persons have different preferences. the 7 tabs you propose may be more relevant!
So in the end, the solution you propose is just OK for me ;-) !

Thanks Charli and lmcapacho for the launch of that new rocket idea :-) !
Big hug

[TimRudy]

It will be a great improvement. Is it Joaquim, or JoJo...?, sorry I don't remember. As to your idea of filtering instead of moving between tabs, I think I like it due to economy, simplicity. I'm not giving a strong opinion. Anyway I was writing to give my 2 cents about the filters in your mock-up. To me, the Tristates are just in the inputs, or in the outputs. Question is, would users have a reason to look at them by themselves, as a type of interesting group? If not, then no Tristate needed. (Naturally, let's see if they get their own column, or an icon or a color code that shows they are special.) Nice, guys!

…

On Fri, Feb 7, 2025 at 8:08 PM jojo535275 ***@***.***> wrote: Hola guys, I think it is a good idea to facilitate the management of I/O/parameters ! My personal preference, will be to not have too many tabs where we can enter the same information (even if as you wrote, their are all automatically updated/synchronized ). Maybe i will keep just the 3 tabs ALL, Manual, tools (maybe also renaming them). We can also imagine to add a filter just above the spread sheet part. something like this: Capture2.JPG (view on web) <https://github.com/user-attachments/assets/b3b5d9e2-d2bb-4f36-81cc-3b51fbf753fe> But has all different persons have different preferences. the 7 tabs you propose may be more relevant! So in the end, the solution you propose is just OK for me ;-) ! Thanks Charli and lmcapacho for the launch of that new rocket idea :-) ! Big hug — Reply to this email directly, view it on GitHub <#873 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6CTIQNUKTG4ONY4TZT4JL2OVKJXAVCNFSM6AAAAABWWWENTGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBZHE4TIOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cavearr]

@jojo535275 I like a lot the idea of checkbox, in this case i think could be better call I/O instead of ALL and remove the MANUAL because is weird for the user, appears other option.

@TimRudy i think this is important to filter tri-state because if you have a block with a lot of inputs and outputs , could be possible to need to filter for search only the bidirectional IO, but your idea that tristate appears on INPUT or with OUTPUT appears me very usefull. In conclusion i think tri-state should appear when the user check on inputs, outputs or tri-state.

Other change that i propose is change tri-state to Bidirectional but the poblem is that in the grid,the word is very large but with the font-size could be possible to do it smaller. Other word to call it is IN/OUT, my preference is Bidirectional (and we need to change all tri-state word in Icestudio to Bidirectional). I'll put both in the mockup to take easy your decisions.

In this way though on this, could be useful that in Icestudio , the bidirectional ports appears in both sides of the block. Now we have to choose between Left or Right side of the block, but this could be a problem in some designs that you need to connect inputs or outputs to it. This is an idea, but what do you think about it? we can mask the two pins in the block as the tristate and for users could be more friendly.

Another thing that I did not mention, the bus width column will contain the number of bits and we will automatically convert to the range internally, for example if the bus width is 16, in manual mode we will convert it to [15:0] and if it were parametric the upper range will be indicated for example N-1 and we will convert to [N-1:0], basically if it is detected that what is entered is a number we will create a range and if it is not a number we will take the literal as the upper limit of the range.

I'm updating the image reference with the proposal and attach the svg file if you want to
edit (sorry, i don't think in attach it in the first message). If you want to edit use inkscape https://inkscape.org/es/release/inkscape-1.4/ and save as svg inkscape format to not lose layers os specific configs (if you modify and attat to this thread).

Thanks for all team!

code_block_v2.svg.zip
examples_v2.zip

[jojo535275]

@TimRudy : My name is Joaquim (or jo mo in google group) ;-)

@cavearr : yes, i like your last mokup even better !
just maybe we can:

• use a single name (or IN/OUT or BIDIrectional )
• gray-out dynamically (when changing the type of a line) the spreadsheet boxes that are not relevant for that type of line (eg: Parameters have no "bus with","sign" possible )
• By defaut, maybe we can check all the "type" checkboxs, then, should we save the checkbox "click state"? Does this saved state applies to all the code blocks. or only to that particular code block ? to be decided !

For the "bus with" options you mentioned (16 value instead 15:0, "parameter" value,...) they are all ok for me !

@TimRudy: About tristates, i will say they should have the right to express, in the icestudio area, their non-binary gender identity ;-)
Now, if they position themself at the left or at the right of the code block, is a politically question ;-).
More seriously, i think it is confusing to call an input "Tristate" (this term is reserved for outputs in electronics).
As you and Carlos suggested the idea of Bidirectionals appearing when the user check on inputs, outputs or Bidirectional is ok for me.
I Also think that showing the bidirectional ports on both sides of a code block is good idea, and in that case maybe we can remove the display at column?! an in manual we will "merge" the two text fields "inout left ports" & " inout rigth ports to a single "InOut ports" field.

So one more mokup version 3, in the following i used Bidi just to show how it could look like, but we can alternatively choose the IN/OUT "name", no preference for me!

And finally the version 4 without the "display at" column ;

code_block_v3.zip

[lmcapacho]

Hi team!

I agree with the changes proposed by @jojo535275 , @cavearr , and @TimRudy . I think Joaquim made that idea clear in version 4.

I have a few observations and proposals:

• I think it's important not to have too many tabs for simplicity, but I think we can add a new tab named "Parameters" because parameters aren't I/O in the design. In this case, the "default value" column wouldn't be necessary in I/O, and parameters would only have "name," "default value," and "enable" columns.

• Another thing I consider necessary is separating "reg" from "sign" options. In the "sign" column, I think it's better to have the three options: 'signed,' 'unsigned,' and 'blank'. In a new column named "reg," there could be a checkbox to enable or disable this option only for output pins.

• I understand the problem with the name "bidirectional," but I think we can use the name "inout," which is the same as in Verilog code.

• Finally, in most other digital design software, the common practice is to use the bidirectional port on the right side. I don't know if having the inout option on both sides at the same time could be confusing. It could be placed only on the right ports. I don't know what the discussion or decision was when Icestudio decided to put the bidirectional option on both sides.

[jojo535275]

@ lmcapacho; Yes, i agree with your "parameter" Tab, and with that no more gray-out needed! the I/O tab will be "simpler"!
Remark: As Carlos wrote sometime an I/O will have a "bus with" value equal to a parameter (eg: WITH_A). But no need to have the parameter (eg: WITH_A) declared on that same I/O tab! So...

I didn't noticed before, that Carlos also put the Reg on the spread sheet!
!Open question ! : Do we really need or want the reg to be mentioned outside the code itself ?
When we see the reg in the code we know that this variable is registered/recorded/buffered.

For the bidirectional/Inout port on both sides, I think it comes from two icestudio team choices:

1 - the idea to allow the user to put a bidirectional pin on the right or on the left of a design! depending how the user is minded!
see this obijuan tutorial (read "Bloque InOut" part and "Bloque InOut-rigth" part )
2 - the idea to allow the user to declare an inout port or insert an "Inout block" anywhere deep inside the icestudio blocks. instead of doing it just before the output FPGA pin (on top level) !

Of course in between (the fpga pin and the Inout block ) you can not insert logic ( or you will get compilation error), but you can wire with join block like this.

Remark: i never tested the circuit above !
But you are right, sometimes limiting the creative possibilities. Can simplify the comprehension!

On our case, reverting back to the single Inout on right side may be more complex:

• changes on certain block libraries mainly "iceIO"
• removing the inout possibilities in the Fpga input ports blocks (the blue ones))
• ,... !
  And there is already a lot to do after all this " incremental ideas process" that we are having here ;-)

[cavearr]

Hi team @jojo535275 @lmcapacho @TimRudy !! This thread becomes very interesting, thank you very much for your involvement!

I will try to present my point of view on the last questions:

PARAMETER TAB

I really like it, this has a different "nature" than IO and I think it is a very good idea to separate it into another tab.
The default value is a new feature, now in icestudio we need to attach a constant block to the code block parameter to assign a default value.

The idea is that in the input text you can write, for example:

BPS=125000, LENGTH, N=8

and if you don't attach any constant blocks, icestudio defaults to this if you specify it.

This will be very useful in the Verilog importer because in many Verilog open source codes, the default value for module arguments appears and we need to be able to manage it.

INOUT NAMING

I like bidirectional much more (or @jojo535275's term bidi ;)) because I keep my eye on the future, on the coming months. I have a very advanced integration of other languages ​​in Icestudio and not all of them use inout in terms of tri-state and bidirectional ports, it seems like a very clear concept to me.

Anyway, if you all prefer INOUT, that's no problem for me, I'm just expressing my point of view.

INOUT PORTS PLACE

Regarding the ports on both sides of the block, I will try to explain myself.

Until I integrated the inout port feature, icestudio did not support this type of bidirectional port or tri-state port. For this, Obijuan in the tutorial pointed out by @jojo535275 implemented the ice40 fpga primitive for this type of port, but it is very limited for two things:

• You need to connect it to the physical pin
• Only valid for the ice40 fpga family.

For this, for mi is not a general solution, it could be useful for some concise applications but not is a general way to work with inout ports. Plus there are a lot of open source projects that use inout ports in modules and we need to be compatible with it. For all of this i decided to implement it.

The integration was a first approximation and in that step I could not invest more time in the graphical integration because I had this thread in mind and I preferred to wait for the best moment to invest our limited time (and this is the moment 😄)

In this first approximation we have a problem in the icestudio graphic system, and that is that you have well-defined input ports on the left and output ports on the right. But...if you have an inout port, what is the right place? At first attempt you might think it is the same, but.... not because it depends on the design. If you want to connect a block with an output port to an input/output port of another, you need its input port to be on the left (you need to connect an output (right) to an input (left)), but if you want to connect an inout port to an input of another block, it must be connected from the right side of the source block to the left side of the destination block.

Internally we would link both ports to the same in the code, the representation as a dual port is only a visual representation.
For this we can't merge the two inputs in the manual tab.

The question is if you see correctly the duplication of the port on both sides and in this case merging the text entry in manual mode for the left/right side.

Or instead, you prefer to stay with the selection for the side.

On the other hand @jojo535275 I do not understand why you indicate the phrase "eliminating the input and output possibilities in the Fpga input port blocks (the blue ones))", by expanding the functionality of this dialog box, we do not need to touch this, in fact the functionality will be expanded but the operation of what already exists will not be changed (that is why the manual mode will be left)

My inout functionality has no relation to Obijuan's IO collection. The IO collection has a set of specific primitives for specific fpga models and is not generic, in fact I think you added some primitives for ECP5, right?

My input functionality (blue blocks) and current input block are generic and yosys infers for us depending on your fpga target.

If I haven't understood something, please tell me!!

OUPUT REG

Now we don't have support for the output reg argument, for Icestudio it is not a problem because we can define a register inside the block and assign it to the output, but it could be very useful to define a checkbox to enable or disable the port registered output, this way in the Icestudio block we would not need to create a register and assign a wire, the output would already be registered.

Also, now with the verilog importer, we need to be able to handle these types of port definitions that appear in a lot of code.

SIGNED / UNSIGNED

now SIGNED is defined in the input text with @ before the port name, this was another thing I tried to define as simple as possible, and it's important to keep this UNSIGNED must be a blank cell (no value)

COLOR

I forgot to add a column for the port color, we don't have this at the moment but as soon as we can configure it (and it is stored) my idea is to activate a development that I have already closed to assign colors to the cables. My idea is that you decide the color of the port and when you connect the cable to that port, the cable takes on that color. If the source and destination have different colors, the cable will take the color of the source (current direction).

In this way it is very convenient to assign cables and for everything to be colored, directed by the port. Because if not, by deleting and adding cables you would then have to configure the color on the cable (unbearable)

Conclusion

and I don't think I've forgotten anything, you tell me anything. If you confirm how you see everything, we can launch a new mockup with the latest decisions.

[lmcapacho]

Hi team!

I was thinking that with these three tabs—IO, Parameters, and Tools—we return to the current window. For this reason, I think it is simpler and more efficient to work on a single screen, as it is now, but with the grids and new options such as: default values for parameters, bidirectional port placement selection, register selection, signed selection, and color.

What do you think about this idea? I can make a mockup if necessary.

I agree with @cavearr on the output register justification. I think it is not ideal to need to create a register and assign a wire just to pass values to an output that changes in an initial or always block.

For the signed option, we can do the same as with the output register, using a checkbox to select between signed and unsigned.

[jojo535275]

@cavearr : When writing my last post, i totally forgot about that feature that you implemented maybe less then one year ago!
I still have problems understand it! My head, struggles with the fact that we can define an fpga pin characteristic from a block hidden deep inside an icestudio design (not on "top level").
As this definition is far from the fpga pin, i fear that it bring synthesis errors if we wrongly insert logic gates in between !?
I think i just need to practice the function! And i will have soon the occasion to do it, because i need to implement an SDRAM controller!

So to summarize, as i feel a bit behind in the understanding of this io-bidi stuff, i will let you guys define the contents of the "spread-sheet" part and try limit myself to give my thought about the GUI part of the thinks ;-)

For the idea of lmcapacho to come back to a single page (no tabs), I am Ok,
But still it will be good to separate parameters.
Maybe something like thaht version 5 of mokup ( + a column for color on I/O spreadsheet) :

code_block_v5.zip

[cavearr]

Hi team! I attach the final version, I think this is the option that covers all our needs, and if it doesn't seem right to you, we can give it as the final version. I think we need two tabs, the idea is to simplify navigation for the user and give them a comfortable and really usable user interface, if we fill each screen with options, we again generate a mess of interface.

For example, "Import code" is not a button that will be used continuously, it is only imported once or a few times, but it is not a constantly used operation, therefore, this button must be in another tab and not visually interfere with continuous use. Very soon we will have other "tools" in this block that I am preparing so that even if now it is for a single button, we leave the interface ready and the user will get used to it.

I love all your proposals guys! Thanks again, we are doing a great job and in a few months the tool will take a big step with all these improvements. For me, we are already moving forward with this. The plan is if you give the ok (we can establish the one we mark with a 👍 and as soon as there are, for example, more than 3, we close it. At that moment I convert it into an issue so that it is already considered a development and any bug or feedback is given in the issue. Is that okay with you and let's move forward?

In principle, @lmcapacho was used to carry the weight, but if there is anything that can help you, let me know.

If it seems good to you, do the 👍 at the bottom-left of this message and I will create the issue (forgive the pain but I want us to get into a certain methodology and order, if you have other suggestions , tell me please!)

I have yet to create more features that I am advancing and working on and I would like to have your input, as well as if anyone wants to take it like @lmcapacho has done with this one, these days I will add. Excuse me if I'm going slowly but I need to advance things and organizing all this also takes a lot of work and I don't want to leave some things standing still for others, my idea is to go like these last few weeks combining organization with progress. Thanks a million.

@lmcapacho @TimRudy @jojo535275

Uploading version6_2.zip…

[jojo535275]

Good for me Carlos.
Just one think. we need a way to scroll down on the spreadsheets (scrollbar or other...), because 6 I/Os are not sufficient for a lot of our future codeblocks !
For the parameters it is less critical, 6 is already reasonable, but...

Gracias to lmcapacho for the coming work ;-)
And if you need some help, if the job can be divided in few task, i can also try give an hand!

[cavearr]

Hi @jojo535275 ! i was updated the prior screenshot and the zip with the scrollbars for clarify.

Sorry for that i'm assuming all the time the scrollbars, but in modern Os, the scrollbars are hidden until you scroll with the mouse or are near the scroll area, this depend of the os but yes, there are scrollbars, you could put infinite ports 😃

The idea is alwais have available blank cells to invite at the user to "define" a new port without the need or has an "add" button or similar.

If the user fill the last availale blank line, the system should add automatically two or three more blank lines, always you have new blanklines 😄

@lmcapacho if you need to add some new external library please comment before add. I'm investing efforts in remove all innecesary dependencies and update as much as possible the external libraries and my ideal is a "zero dependency" app.

If we add a new library for a very complex task, the idea is research for a library that could be useful for other iceStudio stuff, not add libraries because npm is like a free candy store 😺 .

As @jojo535275 if you think that we could help you in some subtasks , tell us if you want. I'm trying the "github projects" could be useful for define task and subtasks, if you want to try i could create a project with the different subtask and assignments that you define.

As we raise the votes >=3 x 👍 , @lmcapacho Go ahead!! 🚀 🤣 i'm trying the projects to view if could be better than issues for this kind of task in the morning i'll take a decision and tell you.

Thanks a lot team!

[lmcapacho]

Hi @cavearr ,

You mentioned that it is not necessary to have an "Add" button and suggested using a blank line for new fields instead. I agree with this proposal. However, I have a question: what about removing fields?

I have started working with the jspreadsheet-ce library, and for now, I don’t need any additional libraries. However, if I need another library, I will let you know before using it to maintain minimal dependencies.

I will continue working on this and review some subtasks that @jojo535275 could be working on.

[cavearr]

Hi @lmcapacho ! thanks a lot for your work.

i think when you removed, you only need to empty(delete) the port name in this momment the hole line should be blank and if there are others below should be moved bottom up, i don't know if the library could be implemented (excel remove row)

In other way we could put a - icon at the end of the row in other column, but in this case we need to check that port never should be blank.