CLK_HZ : REAL := 33.554432E6 -- 2^25
.
.
.
constant MS_MAX_Cnt : integer := integer(ROUND(CLK_HZ/1000.0)) - 1;

What should be the value of MS_MAX_Cnt, 33,555, 33,554 or 33,553?

I say 33,553, the Aldec simulator says 33,554. Who's right?

What am I missing about the operation of ROUND ?

The definition says it adds 0.5 before taking the FLOOR of positive values. Even with the 0.5 added the FLOOR should make the value 33,554.0 then with the integer conversion 33,554 then minus 1 to give 33,553.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, September 18, 2020 at 1:25:09 PM UTC-4, Rick C wrote:

CLK_HZ : REAL := 33.554432E6 -- 2^25
.
.
.
constant MS_MAX_Cnt : integer := integer(ROUND(CLK_HZ/1000.0)) - 1;

What should be the value of MS_MAX_Cnt, 33,555, 33,554 or 33,553?

I say 33,553, the Aldec simulator says 33,554. Who's right?

What am I missing about the operation of ROUND ?

The definition says it adds 0.5 before taking the FLOOR of positive values. Even with the 0.5 added the FLOOR should make the value 33,554.0 then with the integer conversion 33,554 then minus 1 to give 33,553.

I'm not sure what I was doing wrong, but I added statements to do the above calculation one step at a time and it's getting the right number correctly now with the original statement. So the count is right, but the time value in the simulation is not
right.

CLK_HZ : REAL := 33.554432E6

constant Clock_Half_Period : time := 500 ms / CLK_HZ;

Clk_gen: Clk <= not Clk after Clock_Half_Period;

The clock period measured in the simulator is always 29.8 ns no matter what resolution I set for the simulation time value. With the resolution set to 10 fs I just measured the time of a clock and it is 29,800 ps. It should be 29,802 ps if rounded.
That 2 ps is about two clock cycles out of the 1 ms time period. I was trying to set limits for an assert to automatically check this time. If I can't get the clock rate right, I won't be able to check any timings to full resolution... although I
suppose the xtal isn't much more accurate than this, slightly lower than 1 clock cycle per ms.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, September 18, 2020 at 4:45:02 PM UTC-4, Rick C wrote:

On Friday, September 18, 2020 at 1:25:09 PM UTC-4, Rick C wrote:

CLK_HZ : REAL := 33.554432E6 -- 2^25
.
.
.
constant MS_MAX_Cnt : integer := integer(ROUND(CLK_HZ/1000.0)) - 1;

What should be the value of MS_MAX_Cnt, 33,555, 33,554 or 33,553?

I say 33,553, the Aldec simulator says 33,554. Who's right?

What am I missing about the operation of ROUND ?

The definition says it adds 0.5 before taking the FLOOR of positive values. Even with the 0.5 added the FLOOR should make the value 33,554.0 then with the integer conversion 33,554 then minus 1 to give 33,553.

I'm not sure what I was doing wrong, but I added statements to do the above calculation one step at a time and it's getting the right number correctly now with the original statement. So the count is right, but the time value in the simulation is not

right.

CLK_HZ : REAL := 33.554432E6

constant Clock_Half_Period : time := 500 ms / CLK_HZ;

Clk_gen: Clk <= not Clk after Clock_Half_Period;

The clock period measured in the simulator is always 29.8 ns no matter what resolution I set for the simulation time value. With the resolution set to 10 fs I just measured the time of a clock and it is 29,800 ps. It should be 29,802 ps if rounded.

That 2 ps is about two clock cycles out of the 1 ms time period. I was trying to set limits for an assert to automatically check this time. If I can't get the clock rate right, I won't be able to check any timings to full resolution... although I
suppose the xtal isn't much more accurate than this, slightly lower than 1 clock cycle per ms.

I thought maybe I had found the problem, Clock_Half_Period being half the clock period getting rounded. But it should still be 14,901 ps so unless it is being rounded at something larger than 1 ps that's not it. The value of Clock_Half_Period is
reported to be 14,900 ps. I tried setting the value to 14,901 ps and it still reports as 14,900 ps. So that seems to be the root of the problem. I can't find a setting that will allow me to set this to the pico second.

I was looking at some code to view this in more detail that uses an Aldec library for time and without changing any of my code other than adding the library and a couple of lines to show the system resolution, it is now showing the value of Clock_Half_
Period as 14,901 ps! Some irony, the Aldec code writes to "output" and it never shows up on the console, so I never got an answer to that one. Anyone knows where that goes?

That gets me close enough. There is still around 10 or 15 ns error in the clock rate over a millisecond and about that much again error because of rounding the count in my circuit, so the total is just under 25 ns error. That's what I set the test to.
Now I'm testing a much slower strobe the same way. No error reports there either. So this seems to be working now. I wonder what happens if I take out the Aldec time library?

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <[email protected]>
Rick C <[email protected]> wrote:

On Friday, September 18, 2020 at 1:25:09 PM UTC-4, Rick C wrote:

CLK_HZ : REAL := 33.554432E6 -- 2^25 . . .
constant MS_MAX_Cnt : integer := integer(ROUND(CLK_HZ/1000.0)) - 1;

What should be the value of MS_MAX_Cnt, 33,555, 33,554 or 33,553?

I say 33,553, the Aldec simulator says 33,554. Who's right?

What am I missing about the operation of ROUND ?

The definition says it adds 0.5 before taking the FLOOR of positive
values. Even with the 0.5 added the FLOOR should make the value 33,554.0 then with the integer conversion 33,554 then minus 1 to give 33,553.

I'm not sure what I was doing wrong, but I added statements to do the above calculation one step at a time and it's getting the right number correctly now with the original statement. So the count is right, but the time value in the simulation is not right.

CLK_HZ : REAL := 33.554432E6

constant Clock_Half_Period : time := 500 ms / CLK_HZ;

Clk_gen: Clk <= not Clk after Clock_Half_Period;

The clock period measured in the simulator is always 29.8 ns no matter what resolution I set for the simulation time value. With the resolution set to 10 fs I just measured the time of a clock and it is 29,800 ps. It should
be 29,802 ps if rounded. That 2 ps is about two clock cycles out of the 1
ms time period. I was trying to set limits for an assert to automatically check this time. If I can't get the clock rate right, I won't be able to check any timings to full resolution... although I suppose the xtal isn't much more accurate than this, slightly lower than 1 clock cycle per ms.

Since VHDL fundamentally works in time, not frequency, why not define
the clock period (or half period) rather than the frequency?

David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, September 19, 2020 at 4:31:37 PM UTC-4, David Higton wrote:

In message <[email protected]>
Rick C <[email protected]> wrote:

On Friday, September 18, 2020 at 1:25:09 PM UTC-4, Rick C wrote:

CLK_HZ : REAL := 33.554432E6 -- 2^25 . . .
constant MS_MAX_Cnt : integer := integer(ROUND(CLK_HZ/1000.0)) - 1;

What should be the value of MS_MAX_Cnt, 33,555, 33,554 or 33,553?

I say 33,553, the Aldec simulator says 33,554. Who's right?

What am I missing about the operation of ROUND ?

The definition says it adds 0.5 before taking the FLOOR of positive values. Even with the 0.5 added the FLOOR should make the value 33,554.0 then with the integer conversion 33,554 then minus 1 to give 33,553.

I'm not sure what I was doing wrong, but I added statements to do the above calculation one step at a time and it's getting the right number correctly now with the original statement. So the count is right, but the time value in the simulation is not right.

CLK_HZ : REAL := 33.554432E6

constant Clock_Half_Period : time := 500 ms / CLK_HZ;

Clk_gen: Clk <= not Clk after Clock_Half_Period;

The clock period measured in the simulator is always 29.8 ns no matter what resolution I set for the simulation time value. With the resolution set to 10 fs I just measured the time of a clock and it is 29,800 ps. It should be 29,802 ps if rounded. That 2 ps is about two clock cycles out of the 1 ms time period. I was trying to set limits for an assert to automatically check this time. If I can't get the clock rate right, I won't be able to check any timings to full resolution... although I suppose the xtal isn't much more accurate than this, slightly lower than 1 clock cycle per ms.

Since VHDL fundamentally works in time, not frequency, why not define
the clock period (or half period) rather than the frequency?

David

Yeah, that's not an entirely bad idea, but it doesn't change the nature of this issue, limited control of resolution in simulation time. Or more accurately, the issue is not understanding how to control the resolution in time. I'm starting to think the
problem I've seen is that the setting I'm adjusting doesn't take effect unless the simulator program is closed and reopened or something similar, like maybe the project. My computer crapped out the other day and the value in simulation is now accurate
to 100 ps.

It is working well enough and I've spent enough time investigating this matter. At least I know that something will ultimately make it work with a new time resolution setting, just not sure if I have to rub my tummy and pat my head while doing it or not.


Thanks for responding.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The previous post is similar to how CreateClock in the OSVVM library works. if you want to check that out, see https://github.com/OSVVM/OSVVM and look at the file TbUtilPkg.vhd. Create clock also allows for non-even duty cycles.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

You could do your clock as:
ClkProc : process
begin
Clk <= '0', '1' after Clock_Half_Period;
wait for Clock_Period;
end process ClkProc ;

Divide by 2 issues will manifest WRT the placement of the rising edge, however, the time period between rising edges is Clock_Period.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 21, 2020 at 12:56:31 PM UTC-4, Jim Lewis wrote:

You could do your clock as:
ClkProc : process
begin
Clk <= '0', '1' after Clock_Half_Period;
wait for Clock_Period;
end process ClkProc ;

Divide by 2 issues will manifest WRT the placement of the rising edge, however, the time period between rising edges is Clock_Period.

Thanks for the suggestion, but I don't think that really addresses the issue which is control of the simulator timing resolution. I think my real issue is the timing resolution setting in the simulator doesn't have an impact until something is reset,
possibly the entire program closing. Until I find out I'm happy with the current 100 ps resolution.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)