create 400 clocks delay for a signal

[john]

Help wanted, thank you in advance;

I have two signals,
signal a: std_logic ;
signal b: std_logic ;

I try to delay "a " 400 clocks , then send to "b",
I use
a <= b after 400 clocks time;
I put the above code into my project, then download to the
FPGA(XC2v3000), the result is wrong,

then I use the "D" flip flop
signal a: std_logic ;
signal b: std_logic ;
signal temp1:std_logic ;
......
signal temp399:std_logic ;


delay : process (CLK)
if( CLK'event and CLK = '1' ) then
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
end process;
then my project runs correctly on the FPGA chip,
I think there is a smart way to write(maybe use loop?)
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
currently I use 400 lines in my code, I am novice in FPGA, I have no
idea how to simplify the code.
thanks

 

[Kai Harrekilde-Petersen]

miller20032004@yahoo.com (john) writes:

Help wanted, thank you in advance;

I have two signals,
signal a: std_logic ;
signal b: std_logic ;

I try to delay "a " 400 clocks , then send to "b",
I use
a <= b after 400 clocks time;
I put the above code into my project, then download to the
FPGA(XC2v3000), the result is wrong,

And it should be - the "after <time>" construction is not synthesizable.
You need to write a state machine (400 stage pipeline comes to mind) to
create the 400 cycle delay.

signal delay_line : std_logic_vector[400 downto 1];

process(clk, rst)
begin
if reset = '0' then
delay_line <= (others => '0');
else if rising_edge(clk) then
b <= delay_line(400);
delay_line(400 downto 2) <= delay_line(399 downto 1);
delay_line(1) <= a
end if;
end process;


(major caveats with the syntax - it's been many moons since I last
wrote in VHDL)


Regards,


Kai

 

I would use a dual-port RAM ...say 512 x 1-bit. The DP RAM will have separate write and read address ports, as well as a 1-bit data input and 1-bit data output ports. The idea is to use an additional counter to generate a sequence of write address. The counter would be designed to roll-over to "000000000" after it reaches "110001111" (399 decimal). Use a comparator to generate a "the count is equal or greater than" signal which would connect to the Synchronous Reset input. It takes less logic to look for an equal or greater-than signal, than to look for an exact match.

Now use a subtract function subtract 400 from the Write Address and use this as the read address. The contraption will write to an address, then 400 clock cycles later it will read the contents of that address.

Since writing, comparing, subtracting, and reading all take some clock cycles themselves, the compare value may have to be adjusted to account for these.

This is similar to how "back in the day" shift registers actually shifted the data through registers. This is what you were trying to do. It is wasteful of registers, especially 400 of them. Now-a-days, the write and read addresses are finagled instead.

best - Robert


On Thursday, August 28, 2003 at 5:07:32 PM UTC-4, john wrote:

Help wanted, thank you in advance;

I have two signals,
signal a: std_logic ;
signal b: std_logic ;

I try to delay "a " 400 clocks , then send to "b",
I use
a <= b after 400 clocks time;
I put the above code into my project, then download to the
FPGA(XC2v3000), the result is wrong,

then I use the "D" flip flop
signal a: std_logic ;
signal b: std_logic ;
signal temp1:std_logic ;
.....
signal temp399:std_logic ;


delay : process (CLK)
if( CLK'event and CLK = '1' ) then
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
end process;
then my project runs correctly on the FPGA chip,
I think there is a smart way to write(maybe use loop?)
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
currently I use 400 lines in my code, I am novice in FPGA, I have no
idea how to simplify the code.
thanks

 

[Gabor]

On Friday, 6/16/2017 8:20 PM, rejohnson.fpga.design@gmail.com wrote:

I would use a dual-port RAM ...say 512 x 1-bit. The DP RAM will have separate write and read address ports, as well as a 1-bit data input and 1-bit data output ports. The idea is to use an additional counter to generate a sequence of write address. The counter would be designed to roll-over to "000000000" after it reaches "110001111" (399 decimal). Use a comparator to generate a "the count is equal or greater than" signal which would connect to the Synchronous Reset input. It takes less logic to look for an equal or greater-than signal, than to look for an exact match.

Now use a subtract function subtract 400 from the Write Address and use this as the read address. The contraption will write to an address, then 400 clock cycles later it will read the contents of that address.

Since writing, comparing, subtracting, and reading all take some clock cycles themselves, the compare value may have to be adjusted to account for these.

This is similar to how "back in the day" shift registers actually shifted the data through registers. This is what you were trying to do. It is wasteful of registers, especially 400 of them. Now-a-days, the write and read addresses are finagled instead.

best - Robert


On Thursday, August 28, 2003 at 5:07:32 PM UTC-4, john wrote:
Help wanted, thank you in advance;

I have two signals,
signal a: std_logic ;
signal b: std_logic ;

I try to delay "a " 400 clocks , then send to "b",
I use
a <= b after 400 clocks time;
I put the above code into my project, then download to the
FPGA(XC2v3000), the result is wrong,

then I use the "D" flip flop
signal a: std_logic ;
signal b: std_logic ;
signal temp1:std_logic ;
.....
signal temp399:std_logic ;


delay : process (CLK)
if( CLK'event and CLK = '1' ) then
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
end process;
then my project runs correctly on the FPGA chip,
I think there is a smart way to write(maybe use loop?)
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
currently I use 400 lines in my code, I am novice in FPGA, I have no
idea how to simplify the code.
thanks

You're responding to a 14-year-old post. However for a fixed delay
using block RAM (at least for Xilinx) you don't need separate read
and write address. In read-before-write mode, you get the data from
a cell just before it is written. Then setting the delay is simply
a matter of deciding where you wrap the count. This can be done in
single-port mode.


--
Gabor

 

[rickman]

Gabor wrote on 6/16/2017 8:59 PM:

On Friday, 6/16/2017 8:20 PM, rejohnson.fpga.design@gmail.com wrote:
I would use a dual-port RAM ...say 512 x 1-bit. The DP RAM will have
separate write and read address ports, as well as a 1-bit data input and
1-bit data output ports. The idea is to use an additional counter to
generate a sequence of write address. The counter would be designed to
roll-over to "000000000" after it reaches "110001111" (399 decimal). Use a
comparator to generate a "the count is equal or greater than" signal which
would connect to the Synchronous Reset input. It takes less logic to look
for an equal or greater-than signal, than to look for an exact match.

Now use a subtract function subtract 400 from the Write Address and use
this as the read address. The contraption will write to an address, then
400 clock cycles later it will read the contents of that address.

Since writing, comparing, subtracting, and reading all take some clock
cycles themselves, the compare value may have to be adjusted to account
for these.

This is similar to how "back in the day" shift registers actually shifted
the data through registers. This is what you were trying to do. It is
wasteful of registers, especially 400 of them. Now-a-days, the write and
read addresses are finagled instead.

best - Robert


On Thursday, August 28, 2003 at 5:07:32 PM UTC-4, john wrote:
Help wanted, thank you in advance;

I have two signals,
signal a: std_logic ;
signal b: std_logic ;

I try to delay "a " 400 clocks , then send to "b",
I use
a <= b after 400 clocks time;
I put the above code into my project, then download to the
FPGA(XC2v3000), the result is wrong,

then I use the "D" flip flop
signal a: std_logic ;
signal b: std_logic ;
signal temp1:std_logic ;
.....
signal temp399:std_logic ;


delay : process (CLK)
if( CLK'event and CLK = '1' ) then
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
end process;
then my project runs correctly on the FPGA chip,
I think there is a smart way to write(maybe use loop?)
temp1<=a;
temp2<=temp1;
.......
b<=temp399;
currently I use 400 lines in my code, I am novice in FPGA, I have no
idea how to simplify the code.
thanks


You're responding to a 14-year-old post. However for a fixed delay
using block RAM (at least for Xilinx) you don't need separate read
and write address. In read-before-write mode, you get the data from
a cell just before it is written. Then setting the delay is simply
a matter of deciding where you wrap the count. This can be done in
single-port mode.

Additionally, I would point out that the counter can be implemented more
efficiently by coding it as a loadable, down counter. You can code it so
the carry chain is used to detect the zero condition (next value will be
less than zero) and load the max counter value, 399 in this case. The load
control and directly load inputs will fit in the same LUTs as the down
counter in most FPGA families. Very efficient and very fast.

--

Rick C

 

[Charles Bailey]

On 2017-06-17 00:30, rickman wrote:

Additionally, I would point out that the counter can be implemented more
efficiently by coding it as a loadable, down counter. You can code it
so the carry chain is used to detect the zero condition (next value will
be less than zero) and load the max counter value, 399 in this case.
The load control and directly load inputs will fit in the same LUTs as
the down counter in most FPGA families. Very efficient and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin
delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

 

[rickman]

Charles Bailey wrote on 6/17/2017 1:25 PM:

On 2017-06-17 00:30, rickman wrote:
Additionally, I would point out that the counter can be implemented more
efficiently by coding it as a loadable, down counter. You can code it
so the carry chain is used to detect the zero condition (next value will
be less than zero) and load the max counter value, 399 in this case.
The load control and directly load inputs will fit in the same LUTs as
the down counter in most FPGA families. Very efficient and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin
delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

This appears to be using 400 registers as an actual shift register, no? I
suppose shift registers (which don't need the output multiplexer) could be
more efficient than block RAM in an ASIC.

I'm curious, why do you still use the notation above for a clock edge rather
than rising_edge(CLK)? Normally this is only seen in students being taught
by teachers who aren't versed in modern methods.

--

Rick C

 

[Charles Bailey]

On 2017-06-17 11:08, rickman wrote:

Charles Bailey wrote on 6/17/2017 1:25 PM:
On 2017-06-17 00:30, rickman wrote:
Additionally, I would point out that the counter can be implemented more
efficiently by coding it as a loadable, down counter. You can code it
so the carry chain is used to detect the zero condition (next value will
be less than zero) and load the max counter value, 399 in this case.
The load control and directly load inputs will fit in the same LUTs as
the down counter in most FPGA families. Very efficient and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin
delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

This appears to be using 400 registers as an actual shift register, no?
I suppose shift registers (which don't need the output multiplexer)
could be more efficient than block RAM in an ASIC.

I'm curious, why do you still use the notation above for a clock edge
rather than rising_edge(CLK)? Normally this is only seen in students
being taught by teachers who aren't versed in modern methods.

No particular reason. It's a very common way of specifying the clock
for sequential logic. For all practical purposes, for both simulation
and synthesis, it's equivalent to rising_edge(CLK).

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.

 

[Allan Herriman]

On Sat, 17 Jun 2017 15:46:01 -0700, Charles Bailey wrote:

On 2017-06-17 11:08, rickman wrote:
Charles Bailey wrote on 6/17/2017 1:25 PM:
On 2017-06-17 00:30, rickman wrote:
Additionally, I would point out that the counter can be implemented
more efficiently by coding it as a loadable, down counter. You can
code it so the carry chain is used to detect the zero condition (next
value will be less than zero) and load the max counter value, 399 in
this case. The load control and directly load inputs will fit in the
same LUTs as the down counter in most FPGA families. Very efficient
and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

This appears to be using 400 registers as an actual shift register, no?
I suppose shift registers (which don't need the output multiplexer)
could be more efficient than block RAM in an ASIC.

I'm curious, why do you still use the notation above for a clock edge
rather than rising_edge(CLK)? Normally this is only seen in students
being taught by teachers who aren't versed in modern methods.

No particular reason. It's a very common way of specifying the clock
for sequential logic. For all practical purposes, for both simulation
and synthesis, it's equivalent to rising_edge(CLK).

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.

I used to specify clocked logic like that last century. I got over it.

Regards,
Allan

 

[rickman]

Charles Bailey wrote on 6/17/2017 6:46 PM:

On 2017-06-17 11:08, rickman wrote:
Charles Bailey wrote on 6/17/2017 1:25 PM:
On 2017-06-17 00:30, rickman wrote:
Additionally, I would point out that the counter can be implemented more
efficiently by coding it as a loadable, down counter. You can code it
so the carry chain is used to detect the zero condition (next value will
be less than zero) and load the max counter value, 399 in this case.
The load control and directly load inputs will fit in the same LUTs as
the down counter in most FPGA families. Very efficient and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin
delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

This appears to be using 400 registers as an actual shift register, no?
I suppose shift registers (which don't need the output multiplexer)
could be more efficient than block RAM in an ASIC.

I'm curious, why do you still use the notation above for a clock edge
rather than rising_edge(CLK)? Normally this is only seen in students
being taught by teachers who aren't versed in modern methods.

No particular reason. It's a very common way of specifying the clock for
sequential logic. For all practical purposes, for both simulation and
synthesis, it's equivalent to rising_edge(CLK).

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.

I'm very surprised this works. Is there something about this notation that
implies a sensitivity list including CLK? It's been too long since I've
studied the rules of VHDL and this is syntax I just don't use.

If there is not an implied wait for CLK to change, this won't work. When
CLK changes to '1' it will trigger correctly, but as soon as the process
exits CLK will still be '1' and will retrigger. So there must be an implied
sensitivity list with CLK to wait for a change in CLK, just like the
CLK'event in the other syntax.

The underlying rules of VHDL are indeed complex. That is why I learned them
once, found basic forms that did what I want to do and don't deviate. Then
I know my stuff will work without needing to always dig down to the
underlying complex rules.

--

Rick C

 

[Charles Bailey]

On 2017-06-17 22:07, Allan Herriman wrote:

On Sat, 17 Jun 2017 15:46:01 -0700, Charles Bailey wrote:

On 2017-06-17 11:08, rickman wrote:
Charles Bailey wrote on 6/17/2017 1:25 PM:
On 2017-06-17 00:30, rickman wrote:
Additionally, I would point out that the counter can be implemented
more efficiently by coding it as a loadable, down counter. You can
code it so the carry chain is used to detect the zero condition (next
value will be less than zero) and load the max counter value, 399 in
this case. The load control and directly load inputs will fit in the
same LUTs as the down counter in most FPGA families. Very efficient
and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

This appears to be using 400 registers as an actual shift register, no?
I suppose shift registers (which don't need the output multiplexer)
could be more efficient than block RAM in an ASIC.

I'm curious, why do you still use the notation above for a clock edge
rather than rising_edge(CLK)? Normally this is only seen in students
being taught by teachers who aren't versed in modern methods.

No particular reason. It's a very common way of specifying the clock
for sequential logic. For all practical purposes, for both simulation
and synthesis, it's equivalent to rising_edge(CLK).

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.


I used to specify clocked logic like that last century. I got over it.

Regards,
Allan

I recently completed a large-scale ASIC design of a 4-pass Reed-Solomon
decoder. I don't have access to the stats at the moment but it contains
10,000's of latches, SRAMs, register arrays, etc. All of the clocked
logic was coded with the "wait until CLK = '1';" style. It simulates
and synthesizes just fine. What's to get over?

 

[Charles Bailey]

On 2017-06-18 20:59, rickman wrote:

Charles Bailey wrote on 6/17/2017 6:46 PM:
On 2017-06-17 11:08, rickman wrote:
Charles Bailey wrote on 6/17/2017 1:25 PM:
On 2017-06-17 00:30, rickman wrote:
Additionally, I would point out that the counter can be implemented
more
efficiently by coding it as a loadable, down counter. You can code it
so the carry chain is used to detect the zero condition (next value
will
be less than zero) and load the max counter value, 399 in this case.
The load control and directly load inputs will fit in the same LUTs as
the down counter in most FPGA families. Very efficient and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin
delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

This appears to be using 400 registers as an actual shift register, no?
I suppose shift registers (which don't need the output multiplexer)
could be more efficient than block RAM in an ASIC.

I'm curious, why do you still use the notation above for a clock edge
rather than rising_edge(CLK)? Normally this is only seen in students
being taught by teachers who aren't versed in modern methods.

No particular reason. It's a very common way of specifying the clock for
sequential logic. For all practical purposes, for both simulation and
synthesis, it's equivalent to rising_edge(CLK).

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.

I'm very surprised this works. Is there something about this notation
that implies a sensitivity list including CLK? It's been too long since
I've studied the rules of VHDL and this is syntax I just don't use.

If there is not an implied wait for CLK to change, this won't work.
When CLK changes to '1' it will trigger correctly, but as soon as the
process exits CLK will still be '1' and will retrigger. So there must
be an implied sensitivity list with CLK to wait for a change in CLK,
just like the CLK'event in the other syntax.

The underlying rules of VHDL are indeed complex. That is why I learned
them once, found basic forms that did what I want to do and don't
deviate. Then I know my stuff will work without needing to always dig
down to the underlying complex rules.

The sensitivity list is implied in the WAIT statement itself. The
statement gets executed whenever there is an event on any signal
included in the statement. It is essentially equivalent to
delay : process (CLK)
if( CLK'event and CLK = '1' ) then
...

Pretty much every book or manual on VHDL and logic design includes the
"wait until CLK = '1';" style as one possible way of coding clocked logic.

 

[Allan Herriman]

On Mon, 19 Jun 2017 17:11:15 -0700, Charles Bailey wrote:

On 2017-06-17 22:07, Allan Herriman wrote:
On Sat, 17 Jun 2017 15:46:01 -0700, Charles Bailey wrote:

On 2017-06-17 11:08, rickman wrote:
Charles Bailey wrote on 6/17/2017 1:25 PM:
On 2017-06-17 00:30, rickman wrote:
Additionally, I would point out that the counter can be implemented
more efficiently by coding it as a loadable, down counter. You can
code it so the carry chain is used to detect the zero condition
(next value will be less than zero) and load the max counter value,
399 in this case. The load control and directly load inputs will
fit in the same LUTs as the down counter in most FPGA families.
Very efficient and very fast.

Or, based on my ASIC mindset, I would code it like this:
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);

begin delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);

This appears to be using 400 registers as an actual shift register,
no?
I suppose shift registers (which don't need the output multiplexer)
could be more efficient than block RAM in an ASIC.

I'm curious, why do you still use the notation above for a clock edge
rather than rising_edge(CLK)? Normally this is only seen in students
being taught by teachers who aren't versed in modern methods.

No particular reason. It's a very common way of specifying the clock
for sequential logic. For all practical purposes, for both simulation
and synthesis, it's equivalent to rising_edge(CLK).

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.


I used to specify clocked logic like that last century. I got over it.

Regards,
Allan

I recently completed a large-scale ASIC design of a 4-pass Reed-Solomon
decoder. I don't have access to the stats at the moment but it contains
10,000's of latches, SRAMs, register arrays, etc. All of the clocked
logic was coded with the "wait until CLK = '1';" style. It simulates
and synthesizes just fine. What's to get over?

If no-one else has to read or reuse your code, you can use whatever
coding style you want as long as your tools are happy with it.

I could argue that it's better to code the way most people code so that
it's easier for a wide audience to understand. Consider the problems
Rickman had understanding the few lines you posted.

The LRM allows for several ways to specify clocked logic. I learned a
few different ways in my initial VHDL training, but my experience has
been that over the last decade or two most people only learn this way:

process (clk)
begin
if rising_edge(clk) then
q <= d;
end if;
end process;

That said, I think it's important to know all the possible ways that
clocked logic can be specified.

Regards,
Allan

 

[KJ]

Charles Bailey wrote on 6/17/2017 6:46 PM:
On Monday, June 19, 2017 at 12:00:01 AM UTC-4, rickman wrote:

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.

I'm very surprised this works. Is there something about this notation
that implies a sensitivity list including CLK?

No, there is no implied sensitivity list. Processes can be written in two forms:
1. With a sensitivity list, in which case it is illegal to use a wait statement within the process.
2. Without a sensitivity list in which case it is legal to use a wait statement.

When you're writing code for synthesis, it is 'safer' to write in the form of #1 since it is a bit more difficult (but definitely not impossible) to write code that can't be synthesized.

When you're writing testbench code, sometimes it can be easier to write it in form #2. Using form #2, a wait statement is not required in order to get everything to compile but such code will fail at run time since the process will keep re-triggering at t=0 and you'll get some form of 'iteration limit exceeded' error.

The advantage to form #2 in testbench code is that it is perfectly permissible to sequentially wait on completely separate signal events like the following:
process
begin
wait until this=that;
wait until rising_edge(moon);
wait until CowsComeHome = '1'
end process;
Presumably you would write it this way because the testing environment for whatever you're testing needs to step through some sequence of steps.

Kevin Jennings

 

[Gabor]

On Sunday, 6/18/2017 11:59 PM, rickman wrote:

In some ways, I tend to prefer this coding style:
delay : process
wait until CLK = '1';
q <= a & q(0 to 398);
end process;

because it's simpler and more compact.

I'm very surprised this works. Is there something about this notation
that implies a sensitivity list including CLK?

Probably beating a dead horse, but an important point here is that
without a sensitivity list, the process runs continuously. So if you
*don't* have a wait (either on an event or a fixed time period) the
process will prevent simulation time from advancing. This is a common
mistake I see in beginner code. It can also be hard to find why the
simulation is stuck if you don't know how to break the simulation and
see what code is currently "executing."

--
Gabor

 

[Thomas Stanka]

Am Dienstag, 20. Juni 2017 02:25:00 UTC+2 schrieb Charles Bailey:

Pretty much every book or manual on VHDL and logic design includes the
"wait until CLK = '1';" style as one possible way of coding clocked logic.

It is, but I bet you will find more tools not supporting this style than tools supporting it when you leave the both major simulator and synthesis tools and have to use other tools.

Additionally it is not as intuitive to understand for beginner that
wait until clk = '1' is in some cases equivalent to rising_edge(Clk) and ofc it will simulate different for clk having more states than only '1' and '0', as '1'=> 'H'=>'1' would be rising edge for your style of code.

As you are aware of this, it is fine for you, but someone else using your code will not see, if you took care of this or it is just by chance sometimes working. And it would have been no problem for you to write "wait until rising_edge(Clk)" to show other using your code what you really intended.

regards,

Thomas