Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 05 13:29

    umarcor on top-subtype

    (compare)

  • Oct 05 13:28

    umarcor on master

    2008: ad tb_top_generic_subtype cosim: add ref to aguinet/drago… (compare)

  • Sep 24 20:07

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 19:59

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 19:54

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 23 01:45

    umarcor on style

    (compare)

  • Sep 23 01:44

    umarcor on run_08

    (compare)

  • Sep 21 23:02

    umarcor on merge-support

    (compare)

  • Sep 21 22:59

    umarcor on master

    merge run_support.py into run.py (compare)

  • Sep 21 22:51

    umarcor on merge-support

    merge run_support.py into run.py (compare)

  • Sep 21 22:34

    umarcor on master

    style deprecate Travis (compare)

  • Sep 21 22:10

    umarcor on style

    test (compare)

  • Sep 21 21:51

    umarcor on style

    deprecate Travis TMP -k (compare)

  • Sep 21 21:47

    umarcor on style

    style deprecate Travis TMP -k (compare)

  • Sep 21 21:32

    umarcor on style

    pathlib support (compare)

  • Sep 21 21:18

    umarcor on runner-string

    (compare)

  • Sep 21 21:18

    umarcor on style

    pathlib (compare)

  • Sep 21 21:12

    umarcor on style

    style (compare)

  • Sep 21 19:48

    umarcor on master

    vhdl_2008: style use type 'string' for top-level… (compare)

  • Sep 21 19:34

    umarcor on runner-string

    use type 'string' for top-level… (compare)

OneWingedShark
@OneWingedShark_gitlab
@d3jones - :point_up: July 20, 2021 7:48 AM - Your nested F-function looks to me like it would be an ambiguous call and, if it is, should be illegal.
Lars Asplund
@LarsAsplund
@JimLewis I did not. I think he went on to Java shortly after and then management. A lost soul 😀
d3jones
@d3jones
@OneWingedShark_gitlab possibly true, but GHDL accepts it, and reports 3.14, without complaint.
Which is why I was having so much trouble with that rule. It is not clear what "Within the specification of a subprogram" modifies. I may very well file a PR on this.
OneWingedShark
@OneWingedShark_gitlab
@d3jones - That's a good idea.
Simon Richter
@GyrosGeier_gitlab
Hi
I'm trying to simulate a board that contains two FPGAs that talk to each other over a bidirectional bus
so I'd like to simulate transport delays for two inout ports that are connected together
obviously, signal u1_io, u2_io : std_logic_vector(15 downto 0); followed by u1 : one port map(io => u1_io); u2 : two port map(io => u2_io); u1_io <= transport u2_io after 10 ps; u2_io <= transport u1_io after 10 ps; is not the way to go
Simon Richter
@GyrosGeier_gitlab
The full simulation has three components connected together on the bus, and I'd like to validate the bus turnaround timing at each boundary
Simon Richter
@GyrosGeier_gitlab
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BidirectionalConnections looks interesting, especially the 'others attribute: u1_io <= transport u2_io'others after 10 ps; u2_io <= transport u1_io'others after 10 ps; sounds like a reasonable syntax, but I'm not sure how well that would translate to three drivers
Jim Lewis
@JimLewis
Like I replied on https://electronics.stackexchange.com/questions/579531/modeling-bidirectional-propagation-delays, I think you need to get access to the tristate controls. Unfortunate it internal to an encrypted IP. Maybe you can work with your vendor to either get them to add configurable delays or to have them put the tristate IO outside of the encryption in their IP.
Jim Lewis
@JimLewis
While we considered things to address bidirectional connections for 1076-2019, nothing got done - it is a hard problem to solve.
Pablo
@pblecua_gitlab

If you "know" when each chip is driving the bus you could try something like:

   p_delays : process(ic1_drive, ic2_drive, ic1_pin_io, ic2_pin_io)
   begin
     ic1_pin_io <= transport 'Z' after (12 ps);
     ic2_pin_io <= transport 'Z' after (13 ps);

     if(ic1_drive) then
       ic2_pin_io <= transport ic1_pin_io after 9 ps;
     end if;

     if(ic2_drive) then
       ic1_pin_io <= transport ic2_pin_io after 11 ps;
     end if;
   end process p_delays;

With:

  • U1 having: any-to-data delay of 10 ps, data-to-Z delay of 13 ps, and X is immediate
  • U2 having: any-to-data delay of 11 ps, data-to-Z delay of 12 ps, and X is immediate

To create ic1_drive and ic2_drive the test bench must look at the control signals in the transaction, and determine what is happening (this may be non trivial).

Pablo
@pblecua_gitlab

A quick test seems to be working as expected (there are some quirks when going to X, but it is a starting point).

Note: In this example the testbench drives the ic1_drive and ic2_drive instead of "calculating" them from other signals. But this makes it easier for the proof of concept.

--------------------------------------------------------------------------------
------------------------------------- ENTITY -----------------------------------
--------------------------------------------------------------------------------
library ieee;
   use ieee.std_logic_1164.all;


entity IC is
  port(
    drive              : in    std_logic;
    clk                : in    std_logic;
    pin_io             : inout std_logic
  );
end IC;

--------------------------------------------------------------------------------
---------------------------------- ARCHITECTURE --------------------------------
--------------------------------------------------------------------------------
architecture RTL of IC is

  signal s_pin_val : std_ulogic := '0';

begin

  pin_io <= s_pin_val when (drive = '1') else 'Z';

   p_set_out : process (clk)
   begin
     if rising_edge(clk) then
       if(drive = '1') then
         s_pin_val <= NOT(s_pin_val);
       end if;
     end if;
   end process p_set_out;
 end RTL;


--------------------------------------------------------------------------------
------------------------------------- ENTITY -----------------------------------
--------------------------------------------------------------------------------
library ieee;
   use ieee.std_logic_1164.all;


entity IC_tb is
end IC_tb;

--------------------------------------------------------------------------------
---------------------------------- ARCHITECTURE --------------------------------
--------------------------------------------------------------------------------
architecture testBench of IC_tb is
  signal clk                : std_logic := '0';
  signal ic1_drive          : std_logic := '0';
  signal ic2_drive          : std_logic := '0';
  signal ic1_pin_io         : std_logic;
  signal ic2_pin_io         : std_logic;

begin

   clk <= NOT(clk) after 50 ps;


   p_delays : process(ic1_drive, ic2_drive, ic1_pin_io, ic2_pin_io)
   begin
     ic1_pin_io <= transport 'Z' after (12 ps);
     ic2_pin_io <= transport 'Z' after (13 ps);

     if(ic1_drive) then
       ic2_pin_io <= transport ic1_pin_io after 9 ps;
     end if;
     if(ic2_drive) then
       ic1_pin_io <= transport ic2_pin_io after 11 ps;
     end if;
   end process p_delays;

   p_stimuli : process 
   begin

     ic1_drive <= '0';
     ic2_drive <= '0';

     wait for 200 ps;
     wait until rising_edge(clk);
     ic1_drive <= '1';

     wait for 500 ps;
     wait until rising_edge(clk);
     ic1_drive <= '0';

     wait for 500 ps;
     wait until rising_edge(clk);
     ic2_drive <= '1';

     wait for 500 ps;
     wait until rising_edge(clk);
     ic2_drive <= '0';

     wait for 500 ps;
     wait until rising_edge(clk);
     ic1_drive <= '1';
     ic2_drive <= '1';

     wait for 500 ps;
     wait until rising_edge(clk);
     ic1_drive <= '0';
     ic2_drive <= '0';

     wait;   -- !!!!!!!! Forever


   end process p_stimuli;


   i_ic1 : entity work.IC(RTL)
   port map(
     clk    => clk,
     drive  => ic1_drive,
     pin_io => ic1_pin_io
   );

   i_ic2 : entity work.IC(RTL)
   port map(
     clk    => clk,
     drive  => ic2_drive,
     pin_io => ic2_pin_io
   );

 end testBench;
Simon Richter
@GyrosGeier_gitlab
Okay, so I'll try to find out if I can somehow get at the enable signal -- it seems to be named <protected>.<protected> though.
Adrian Byszuk
@abyszuk

Hello everyone! I need your advice on coding style. There are cases where I'm still struggling how to handle it.
Assuming that we want to, more or less, adhere to 80 chars per line rule how would you format this:

constant c_board_type : std_logic_vector(15 downto 0) := std_logic_vector(to_unsigned(g_board_type, 16));
                                                                          --  ^ - 80 char limit

Should it look like this:

constant c_board_type : std_logic_vector(15 downto 0) :=
  std_logic_vector(to_unsigned(g_board_type, 16));

or like this:

constant c_board_type : std_logic_vector(15 downto 0) := std_logic_vector(
                                                         to_unsigned(g_board_type,
                                                                     16));

Same goes for example for function calls, where even the lenght of a single argument exceeds the 80 char limit.

write_to_ifc(adr_i => std_logic_vector(to_unsigned(ADDR_TOP_LEDS+ADDR_IN_OUT_REGS_POR, 32)), dat_i => x"0000_0000", perr_i => "0000", ptype_i => tb_ifc_parity_c);
                                                                       --  ^ - 80 char limit

Should I just ignore this rule to fit the whole argument in one line:

write_to_ifc(adr_i => std_logic_vector(to_unsigned(ADDR_TOP_LEDS+ADDR_IN_OUT_REGS_POR, 32)),
             dat_i => x"0000_0000", perr_i => "0000",
             ptype_i => tb_ifc_parity_c);
                                                                       --  ^ - 80 char limit

Or do you have better ideas?

It doesn't have to be 80 chars, can be 100 or 120. I'm just curious how to break the lines so that it looks reasonable.
Adrian Byszuk
@abyszuk
(damn gitter chat, it's so hard to get space alignment right in the code blocks)
Lars Asplund
@LarsAsplund
@abyszuk Unless you have support for formatting in the editor that can maintain aligning I would suggest the first format. The rationale is that if you refactor your code and decide to rename c_board_type to something with a different length you don't have to manually update the alignment of the second line.
d3jones
@d3jones
The second example also works. It's split at a logical point to fit within width constraints, and the split point and indentation are not a function of identifier length, so this survives refactoring.
GlenNicholls
@GlenNicholls

@abyszuk I usually stick to the following for code I am authoring:

constant c_board_type : std_logic_vector(15 downto 0) := std_logic_vector(
    to_unsigned(g_board_type, 16)
);

or this which I think is a bit more readable. The above is what I would do for assigning a record of some sort

constant c_board_type : std_logic_vector(15 downto 0) :=
    std_logic_vector(to_unsigned(g_board_type, 16));
constant rec : record_t := (
    a => x"001",
    b => x"123",
   -- many more values here that make assigning on a single line difficult to read
);
...
write_to_ifc(
    adr_i => std_logic_vector(to_unsigned(ADDR_TOP_LEDS+ADDR_IN_OUT_REGS_POR, 32)),
    dat_i => x"0000_0000", 
    perr_i => "0000",
    ptype_i => tb_ifc_parity_c
);

I personally don't like aligning things with the first parenthesis because it requires you to have weird line breaks if the code is indented quite far or the line is verbose. I am strict about line limits in my code, but sometimes it just doesn't make sense to break the line up because it makes it harder to read so I just try a few things in those cases to determine what makes the most sense.

Another thing I prefer when breaking up a line is to have each parenthesis break on it's own line and indent the contents to make hunting for missing commas or semicolons easier:

write_addr(
    addr => std_logic_vector(
        to_unsigned(16, 32)
    ),
    data => x"ffff"
);

The verbosity of VHDL is really annoying for this and I absolutely hate having to scroll the editor horizontally to read code or adjust the editor. My company has common packages for things like type casting, e.g. to_slv, that we overload for multiple types. This helps a lot with the verbosity. I hate typing the same things over and over so I prefer this in cases where those functions/procedures actually make sense to be in a common package, but I know people that feel that style goes against the objective of an HDL... IMO, the most important thing is to be consistent

Lars Asplund
@LarsAsplund
I'd love a commonly used FOSS formatter like black for Python. There is never going to be consistency within a project without that. Just in these comments we have different alignment styles different number of spaces for indentation.
With the risk of starting a flaming war the most common indentation on GitHub is 2 spaces. Research has shown that optimal indentation should be in the 2 - 4 range. Logically a common formatter would use 2 spaces without any option to change that. Agree?
Richard Head
@trickyhead_gitlab
@LarsAsplund someone will suggest tabs next and it goes nuclear
Patrick Lehmann
@Paebbels
tabs where made for indentation :)
GlenNicholls
@GlenNicholls
Agreed. If there was a formatter like black for VHDL, I would be more than happy to adjust my style based on recommendations. IMO, unless you have some way of enforcing or formatting code automatically, a recommended style guide for VHDL will not go very far.
Patrick Lehmann
@Paebbels
A formatter would be good, but black is a very bad example for "good" formatter as it produces lot's on inconsistencies in the output. At some point code becomes longer, unreadable and has an average line length auf 20-40 chars instead of 80 chars ...
GlenNicholls
@GlenNicholls
Well yeah, bad example. However, my point was that if there isn't a way to automate checking acceptable styles, developers are not going to be checking their code against the style guide before they commit.
Patrick Lehmann
@Paebbels
@GlenNicholls :thumbsup:
Lars Asplund
@LarsAsplund
Agree, black can be improved but the value of not having the style issues greatly exceeds the problems it has so I use it anyway. It's also limited in terms of configuration which prevents everyone from creating their own dialect. If someone comes up with a way to handle its issues then everyone will "automatically" align to that.
ktbarrett
@ktbarrett:matrix.org
[m]
There is VHDL style guide, which is somewhat mature. Unlike Black it gives the user a lot of options to tweak formatting. I'm not sure if that's a good thing.
GlenNicholls
@GlenNicholls
Luca Colombini
@lukipedio
VSG is what TesosHDL is using for example. They also cite VHDL formatter (https://github.com/g2384/VHDLFormatter)
Lars Asplund
@LarsAsplund
Let me put some gasoline on that fire. There is a study on casing that concludes that CamelCase improves readability. It was based on asking people mostly used to CamelCase what they thought was the style easiest to read. Then there was a follow-up study using eye tracking to measure the difficulty to read different styles. That study didn't have the CamelCase bias as the first study had. The conclusion was that snake_case was easier to read for beginners but that the difference disappears once you get used to a style. Scientifically there is no benefit of using one over the other. What's more common? On GitHub snake_case is more common (3/4). Logically a common style would be based on....
Luca Colombini
@lukipedio
snake_case ahah Well CamelCase doesn't make much sense for a "almost" case-insensitive language like VHDL. You don't only need to read your code, but to track signals in debug also for instance
Kaleb Barrett
@ktbarrett
@GlenNicholls Yeah VSG. One missing feature is that it doesn't seem to handle naming conventions.
Luca Colombini
@lukipedio
@LarsAsplund Thanks for reposrting data from different studies. My feeling is the same as it seems to emerge from them. Get a "good" style and stick to it.
Jim Lewis
@JimLewis
@LarsAsplund @umarcor @Paebbels Did you see that ARM came up with new terminology.
AXI: Regularized terminology to use Manager to indicate the agent that initiates transactions and Subordinate to indicate the agent that receives and responds to requests
AxiStream has a Transmitter and Receiver
Ironic definitions on AXI as I had decided that the appropriate name would be used in its definition - that is how I came up with responder - and they use responds in the definition. Missed opportunity to make some sense. Maybe it makes more sense in another language?
Will be updating AXI terminology in the next OSVVM release. Looks like I picked the obvious choice for AxiStream.
Jim Lewis
@JimLewis
WRT styles, some of the Ada styles I have seen seem to merge camel and snake: Camel_Snake_Case
Jim Lewis
@JimLewis
WRT styles, camel vs snake case, that is a great way to start a flame war.
It would not be possible to change even just the interface to OSVVM without some automated tool. Otherwise, what would the value be?
Lars Asplund
@LarsAsplund

@JimLewis

WRT styles, some of the Ada styles I have seen seem to merge camel and snake: Camel_Snake_Case

So many cases. Have no idea what this is called but I learned that we should differentiate between PascalCase and camelCase and that there is something called kebab-case

WRT styles, camel vs snake case, that is a great way to start a flame war.

It is, I try to raise this question once in a while to see what the state of the community is

It would not be possible to change even just the interface to OSVVM without some automated tool.

I don't think this particular formatting case would be very hard. Use pyVHDLParser to extract public APIs and then use something like these short Python functions to convert the names.

Otherwise, what would the value be?

The primary value I see in a community-wide style for things like indentation, casing and line endings is that it simplifies cooperation in developing open source code. If there is no common style for these things then any style is allowed which means that this will be a topic open for discussion in every code review. Such discussion tend to take focus from the more important things to review. Styles will also change back and forth when different developers update files. A small change looks like a large one just because the developer had another indentation setting in her editor.

Some automatically enforceable styles have been shown to have a measurable effect on things like readability and bug rate. Those are few, the only one I've seen been supported in research is the line length limitation.

Then there are rules which are hard to automatically enforce but have great value. Meaningful identifier names for examples.

There are also rules that have been shown to make things worse so there's no point in creating rules mindlessly just because we can.

Jim Lewis
@JimLewis

Some automatically enforceable styles have been shown to have a measurable effect on things like readability and bug rate. Those are few, the only one I've seen been supported in research is the line length limitation.

I would say trying to attribute lower bug rate to that is dubious. The people and teams who choose to use automatically enforced styles are likely to be more disciplined and have a lower bug rate anyway.

I have seen the Ada style. It would be a compromise. Which is likely what happened.